cancel
Showing results for 
Search instead for 
Did you mean: 

bpstart_notify and updating /etc/hosts file on media server

Dangerous_Dan
Level 5
Partner Certified

Hello All,

I have been wokring with my network team to try to figure out how to resolve the following issue.

We have a customer with several Windows clustered file servers.

I am aware of the best practices for protecting clustered file servers (virtual IP) but for this customer we cannot do this because we use PVLAN's and so transferring the virtual IP would cause it to be blocked because it is assigned to the other nodes MAC address.

An idea popped up to use a bpstart_notify script to perhaps update the cluster IP to the other nodes IP in the /etc/hosts file on the media server but I don't know if this is even possible.

The idea at the time of the backup is for bpstart_notify to:

  1. Check current configured IP address for cluster for active node (from command line)
  2. if node 1 is active then update /etc/hosts on media server from 192.168.0.12 to 192.168.0.13
  3. if node 2 is active then update /etc/hosts on media server from 192.168.0.13 to 192.168.0.12

Then run the backup.

 

My questions are:

do you think this is feasible?

will the bpstart_notify work on the media server per policy/client? I don't want this to run for every backup if I run it on the media server.

1 ACCEPTED SOLUTION

Accepted Solutions

Dangerous_Dan
Level 5
Partner Certified

Hi All,

 

In the end despite my best efforts, none of the suggested solutions were able to fix my issue.

 

I ended up writing an SOP to my team if a failover occured, then they just move the cluster alias name to the other node. This is going to just be a workaround until the end of the year when our network refresh occurs

View solution in original post

11 REPLIES 11

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

How do clients access the file shares if they're not using a Virtual IP?

Dangerous_Dan
Level 5
Partner Certified

@RiaanBadenhorst wrote:

How do clients access the file shares if they're not using a Virtual IP?


Hi,

The customer facing network is their own network where they access their machines but the backup network adapters are connected to a PVLAN. They have a VIP configured on that network.

we are a managed service so we have multitenancy Netbackup environments and the most secure way to keep customers segregated from each other is with a PVLAN.

Hi @Dangerous_Dan 

If I understand you correctly, on the backup network there is no VIP available and you can only access each node of the cluster. I can think of two ways you could manage this.

1. Run the backup against both nodes - the inactive node will complete quickly (or may fail due to no drives to backup). Create host aliases so that the backups from each node are registered against the cluster name. 

2. Run a "dummy" backup policy on the media server (this assumes the media server can identify the correct active node). This backup has a bpstart_notify script that determines the active node, then initiates a backup for that node "bpbackup -i -w -p <Policy> -h <active node> -s <schedule>". The "-i" tells NetBackup to start this backup immediately, the "-w" says to wait until the backup complets. The wait option may not be needed but if you do use it you will almost certainly need to increate the bpstart start notify timeout on the media server. 

Cheers
David

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

@Dangerous_Dan 

It is possible to add a VIP on the backup network.
I have seen this being done on Microsoft Cluster and Veritas Cluster.

Or else follow @davidmoline's advice for easiest solution.

jnardello
Moderator
Moderator
   VIP    Certified
Situations like this might be a reason to bring up dropping customer-dedicated Media Servers into those subnets in the future, then those Media Servers just have a couple of firewall ports opened to communicate metadata back to the Master. Right now you're having to architect a solution around someone's deployment choice that obviously didn't take backups into account - and there's a reason it's called "best practices" in the first place, right ? =) Using a dedicated Media Server (which of course gets billed to the customer somehow as part of their backup bill) will easily allow a single Master to do multi-tenancy without exposing one customer's data to another. Food for thought during your next architecture meeting.

Dangerous_Dan
Level 5
Partner Certified

@jnardello wrote:
Situations like this might be a reason to bring up dropping customer-dedicated Media Servers into those subnets in the future, then those Media Servers just have a couple of firewall ports opened to communicate metadata back to the Master. Right now you're having to architect a solution around someone's deployment choice that obviously didn't take backups into account - and there's a reason it's called "best practices" in the first place, right ? =) Using a dedicated Media Server (which of course gets billed to the customer somehow as part of their backup bill) will easily allow a single Master to do multi-tenancy without exposing one customer's data to another. Food for thought during your next architecture meeting.

Hi,

Although yes dropping in a media server on the customers network is an easy solution, it isn't very efficient. we use MSDP pools to reduce the need of multiple media servers. It would mean the customer would have to pay for i.e. VM's resources for this media server + they have their data replicated to other DC's and therefore would be a pain for us to setup this media server to perform the replication. I don't think our security would even approve it.

 

Dangerous_Dan
Level 5
Partner Certified

@davidmoline wrote:

Hi @Dangerous_Dan 

If I understand you correctly, on the backup network there is no VIP available and you can only access each node of the cluster. I can think of two ways you could manage this.

1. Run the backup against both nodes - the inactive node will complete quickly (or may fail due to no drives to backup). Create host aliases so that the backups from each node are registered against the cluster name. 

2. Run a "dummy" backup policy on the media server (this assumes the media server can identify the correct active node). This backup has a bpstart_notify script that determines the active node, then initiates a backup for that node "bpbackup -i -w -p <Policy> -h <active node> -s <schedule>". The "-i" tells NetBackup to start this backup immediately, the "-w" says to wait until the backup complets. The wait option may not be needed but if you do use it you will almost certainly need to increate the bpstart start notify timeout on the media server. 

Cheers
David


Hi,

Suggestion 1 sounds more ideal. How do I "Create host aliases so that the backups from each node are registered against the cluster name"?

Dangerous_Dan
Level 5
Partner Certified

Hi @Marianne 

VIP's on our Backup network are not possible because the IP's are assigned to the VM's network adapters MAC address.

When you failover the VIP to the other node in the cluster, the switch security see's this and stops traffic going to the new adapter as it has a different MAC attempting to use it.

Thanks

Dan

Hi Dan

The bpclient command is the one to use

bpclient -client client_name [-M master_server] -add_alias alias_name

Further discussion on this topic can be found here:

https://www.veritas.com/support/en_US/article.100009879

As well as updating NBDB with the association the image directories are also linked. One of the tricky bits is to manage the links appropriately. Ideally the host cluster name directory will contain all the images. The individual node names will simply be symlinks (Unix) or ALTPATH directives (Windows). Refer to the section towards the bottom of the article on merging the image database for more details around this.

It looks complicated (and probably is) but it is worth doing properly for this type of situation. 

Good luck.

 

Dangerous_Dan
Level 5
Partner Certified

@davidmoline wrote:

Hi Dan

The bpclient command is the one to use

bpclient -client client_name [-M master_server] -add_alias alias_name

Further discussion on this topic can be found here:

https://www.veritas.com/support/en_US/article.100009879

As well as updating NBDB with the association the image directories are also linked. One of the tricky bits is to manage the links appropriately. Ideally the host cluster name directory will contain all the images. The individual node names will simply be symlinks (Unix) or ALTPATH directives (Windows). Refer to the section towards the bottom of the article on merging the image database for more details around this.

It looks complicated (and probably is) but it is worth doing properly for this type of situation. 

Good luck.

 


Thanks - something I can get my teeth in.

 

I'll report back on whether this works for my situation.

Dangerous_Dan
Level 5
Partner Certified

Hi All,

 

In the end despite my best efforts, none of the suggested solutions were able to fix my issue.

 

I ended up writing an SOP to my team if a failover occured, then they just move the cluster alias name to the other node. This is going to just be a workaround until the end of the year when our network refresh occurs