Start a Conversation

Unsolved

This post is more than 5 years old

5393

July 28th, 2016 14:00

DDOS CLI command to create a DDBOOST storage path.

Hi all,


Issue:

When I start the NetWorker device wizard to add a new DD and create devices, after entering the ddboost user and password, which I know are correct, there's a timeout error. The wizard then asks if you want to create the device manually, which I don't see the logic in asking because the storage path doesn't exist yet as you have to create it through the wizard, which is failing.

If I manually create the device and then try to mount it, I get:

Opening the file '/nws/SN_TEST2/volhdr' failed [5004] [680] Thu Jul 28 17:03:02 2016

ddp_open_file() failed for File: //nws/SN_TEST2/volhdr, Err: 5004-nfs lookup failed (nfs:No such file or directory)

The above is expected because aside from the wizard, the manual device creation process doesn't command DD to create the storage path you are entering manually.

So I wondered if there's a DDOS CLI command to create a storage path under a NetWorker mtree, from a PuTTY session? Does it exist?

I was looking at "ddboost storage-unit create" but didn't go far.

Regards,

Armando

14.3K Posts

July 28th, 2016 15:00

One is  mtree create and second one ddboost storage-unit create to pay attention.  But if it fails in your case, normally it means that one of the boxes in process of wizard might not have access to this.  Last time I have seen this was when I was trying to define DD box on VLAN which was accessible from backup server and storage nodes, but not from NMC server (it didn't have this specific VLAN which would be used for DDboost communication).  Short workaround for me was to temporary install NMC also on backup server and run wizard from that box.  If you believe this is all ok in your case, then you should inspect logs on DD (create support bundle and check logs after another attempt so that you can write down exact time when you did it - it helps narrow down search).

96 Posts

July 29th, 2016 11:00

Please check if ddboost user is not locked in Data Domain.

14 Posts

August 26th, 2016 12:00

Hi guys,

Appreciate your comments! Eventually the link seemed to improve a bit, maybe less traffic that day, and I was able to create the device.

The link between the two sites is about 5.9 MBps (bytes per second), shared by other enterprise traffic.

I did notice some delays in the connection between the main and remote site. When you click on next right after providing the ddboost user name and password, you will normally see the progress bar flashing/blinking repeatedly quite fast, but in this case it was slow, although eventually the next screen of the wizard showed up.

iperf test revealed (iperf client is NW server, iperf server is the DD appliance):

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

Client connecting to xxxxxxxxx, TCP port 5001

TCP window size:  208 KByte (default)

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

[  3] local xxx.xxx.xxx.xxx port 58452 connected with xxx.xxx.xxx.xxx port 5001

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-10.0 sec  2.00 MBytes  1.68 Mbits/sec

[  3] 10.0-20.0 sec  2.50 MBytes  2.10 Mbits/sec

[  3] 20.0-30.0 sec  1.62 MBytes  1.36 Mbits/sec

[  3] 30.0-40.0 sec  2.12 MBytes  1.78 Mbits/sec

[  3] 40.0-50.0 sec  2.12 MBytes  1.78 Mbits/sec

[  3] 50.0-60.0 sec  1.62 MBytes  1.36 Mbits/sec

[  3]  0.0-60.7 sec  12.0 MBytes  1.66 Mbits/sec

The optimal MTU is around 1470 (measured with ping). I noticed ping RTT seems high? I don't know because I've never seen anything documented regarding at what RTT Data Domain starts to be affected:

Pinging xxx.xxx.xxx.xxx with 32 bytes of data:

Reply from xxx.xxx.xxx.xxx: bytes=32 time=660ms TTL=60

Reply from xxx.xxx.xxx.xxx: bytes=32 time=825ms TTL=60

Reply from xxx.xxx.xxx.xxx: bytes=32 time=692ms TTL=60

Reply from xxx.xxx.xxx.xxx: bytes=32 time=659ms TTL=60

Any ideas greatley appreciated!

14.3K Posts

September 8th, 2016 01:00

I could be wrong but I think in the past for ddboost time shouldn't have been more than 20ms...

No Events found!

Top