cancel
Showing results for 
Search instead for 
Did you mean: 

SAN Client service takes a long time to start

mtaormina
Level 3

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 ACCEPTED SOLUTION

Accepted Solutions

CRZ
Level 6
Employee Accredited Certified

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 6

SymTerry
Level 6
Employee Accredited

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.

 

mtaormina
Level 3

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.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Probably best to log a Support call...

mtaormina
Level 3

Marianne,

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

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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....

 

CRZ
Level 6
Employee Accredited Certified

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)