Unsolved
7 Posts
0
5123
two servers with same hostname but different IP
Hi all,
I'm looking for a possibility to have 2 servers (different IP) with same hostname in one Networker zone. The background on this :
1. My SAP guy does have SAP servers with same hostname that 1 located on site A and the other on site B (for DR purpose)
2. They don't want to change the hostname on the site B as it would be a lot effort to do.
3. Current situation: if I want to perform a restore SAP data from a server with hostname sap_ecc1 (ip 10.14.99.31 on site A) TO a server with same hostname sap_ecc1 (ip 10.14.63.68 on site B), I have to delete the client sap_ecc1 (ip 10.14.99.31) on NMC and delete the nsr peer information. Add the sap_ecc1 (ip 10.14.63.68) and perform a restore. That would be a lot work to do, and I can't perform the restore with the situation the server with IP 10.14.99.93 running a backup.
Is there a more simple way to perform a data restore of sap_ecc1 (ip 10.14.99.31) to sap_ecc1 (ip 10.14.63.68) without have to perform point I mentioned above ?
FYI, i tried to fool Networker by aliasing eccprod as eccproddr in the /etc/hosts of server with ip 10.14.63.68 and add this eccproddr in the Networker client resource. It does success.... but I got a message on the log that it conflicting with eccprod 10.14.99.93. And restore got a problem as eccproddr not listed on the nsr peer information.
I appreciate for the inputs and workaround.
Best Regards,
Martin
bbeckers1
1 Rookie
1 Rookie
•
102 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.