you are trying to solve an issue that is not yours to solve. its a bit peculiar to have a DR system already up and running with the same name as the server it is supposed to act as DR for. sounds like poor mans DR especially with no effort to be done by sap team? so they want to have a backup if the DR system while it has the same name as another system. so as sap is not willing to change due to effort on their end, the backup admin has to put in the effort? it's their "solution" (and a poor one at that). resolving via dns or what? in case of DR they would point to the DR system IP instead? or via host entries? regardless if both systems are up at the same time not that good an idea. even if DR system would be down, then as you stated you'd have to delete nsr peer info. that should be telling you the approach is wrong as the same would have to be done yet again if the original system becomes available again. if DR is to be used, it could be towards another system. then both can be in backup without a problem. or have HA via oracle dataguard or other HA/clustered solutions with for instance a standby DB. If another system is to takeover functionality under the same as the original system, then something should be put into place to perform for instance the rename of such a system. or have it down but at times arrange it to have its configuration synchronised (or replicated on storage level) But I guess as this is the DR "solution" my guess is we are dealing here with physical systems?, doing things better or smarter on the client/application end is no option budget wise? if not restore to another system with a different name (and then pointing towards that), or (application) clustering, then virtualization with ideally HA possibility? Options are legion, costs will vary. a complete rebuild of a system would ofcourse also require nsr peer info to be deleted but calling it a design to have 2 systems with the same name active at the same is odd without making sure you can tell the difference apart from their ip address. I'd send them back to the drawingboard and come up with something better.
Thanks and I appreciate for your inputs. Responding to your questions: as both servers are not registered on DNS, they will not conflict each other and yes they are both are physical servers. I agree with you, there are many options and at the end of the day it matters of cost. The reason why they don't want to take the effort re-design the existing system actually because the feel convenient/suffice with what they do on business needs. Earlier when they use BRTools to backup direct to DD VTL, this won't be an issue. So that's why they expect the same when the backup changed to Networker. I have contacted support on this and still testing several things, like registering the SAP on the DR by IP in the client resources. We'll see if this possible.
bbeckers1
2 Intern
•
203 Posts
0
December 4th, 2018 15:00
you are trying to solve an issue that is not yours to solve. its a bit peculiar to have a DR system already up and running with the same name as the server it is supposed to act as DR for. sounds like poor mans DR especially with no effort to be done by sap team? so they want to have a backup if the DR system while it has the same name as another system. so as sap is not willing to change due to effort on their end, the backup admin has to put in the effort? it's their "solution" (and a poor one at that). resolving via dns or what? in case of DR they would point to the DR system IP instead? or via host entries? regardless if both systems are up at the same time not that good an idea. even if DR system would be down, then as you stated you'd have to delete nsr peer info. that should be telling you the approach is wrong as the same would have to be done yet again if the original system becomes available again. if DR is to be used, it could be towards another system. then both can be in backup without a problem. or have HA via oracle dataguard or other HA/clustered solutions with for instance a standby DB. If another system is to takeover functionality under the same as the original system, then something should be put into place to perform for instance the rename of such a system. or have it down but at times arrange it to have its configuration synchronised (or replicated on storage level) But I guess as this is the DR "solution" my guess is we are dealing here with physical systems?, doing things better or smarter on the client/application end is no option budget wise? if not restore to another system with a different name (and then pointing towards that), or (application) clustering, then virtualization with ideally HA possibility? Options are legion, costs will vary. a complete rebuild of a system would ofcourse also require nsr peer info to be deleted but calling it a design to have 2 systems with the same name active at the same is odd without making sure you can tell the difference apart from their ip address. I'd send them back to the drawingboard and come up with something better.
Obi_Wan_Abud
7 Posts
0
December 5th, 2018 04:00
Hi Berry,
Thanks and I appreciate for your inputs. Responding to your questions: as both servers are not registered on DNS, they will not conflict each other and yes they are both are physical servers. I agree with you, there are many options and at the end of the day it matters of cost. The reason why they don't want to take the effort re-design the existing system actually because the feel convenient/suffice with what they do on business needs. Earlier when they use BRTools to backup direct to DD VTL, this won't be an issue. So that's why they expect the same when the backup changed to Networker. I have contacted support on this and still testing several things, like registering the SAP on the DR by IP in the client resources. We'll see if this possible.