Spring Cloud Services Starter Service Registry Issue with Version 1.6.x series about spring-cloud-services-starters

[csterwa]

@dilipmighty245 the Diego IP access is no longer supported as of 1.4.0.RELEASE. This was removed in favor of Container Networking support and the direct mode was modified to use this approach instead. There were technical issues with the direct Diego IP address approach that were found with customer use cases. I'm not aware of any implementation doing cross-DC registrations though so this is a new one.

There are ways that this can be accomplished using different methods. Can you describe in more detail what your HA use is. Could peer replication meet the same need for registering apps in both locations although not using direct mode? In addition, are these DCs located in a proximity that using a common network fabric could be used. It sounds like this might have been the case already considering the 198.x.x.x access across DCs?

[dilipmighty245]

Hi @csterwa ,

Thanks for the quick response,

• The scenario is, my Application is running in Two DCs with 2 instances per DC.
• Simple Architecture : Zuul<->Eureka<->App
• The Eureka in both DCs are peers(Im Using Spring Cloud Services)
• If services in one DC is Down, the requests go to another DC. However, the application is registering with its container IP, Zuul is not able to connect with the application, throwing the following error:
  Caused by: org.apache.http.conn.HttpHostConnectException: Connect to 10.x.x.x:80 [/10.x.x.x] failed: Connection refused (Connection refused)
• When we were using 1.3.1.RELEASE, the apps are registering with Diego IP, and we never faced any issue even services are down in another DC. ( Never faced connection refused/timeout issue)
• Both DCs are not in proximity
• If I use the registration method as route instead of direct, One DC throw Connection Refused, and the Zuul which is in the same DC as App throws I/O exception (java.net.NoRouteToHostException) caught when processing request to {}->http://10.x.x.x:80: No route to host (Host unreachable)

Note: Network policies are added between Apps

[csterwa]

@dilipmighty245 the last item on your list:

"If I use the registration method as route instead of direct, One DC throw Connection Refused, and the Zuul which is in the same DC as App throws I/O exception (java.net.NoRouteToHostException) caught when processing request to {}->http://10.x.x.x:80: No route to host (Host unreachable)"

It is interesting that when registering with Eureka via route mode it is providing an IP address of 10.x.x.x as the host? I thought that this would be the app's mapped route on PCF with the domain instead of IP address. Does the Zuul implementation use the IP address only when making the connection or can it use host instead?

[dilipmighty245]

@csterwa Yes you are right, it is registering with Eureka with App route, the issue I found is
I had added ribbon.IsSecure=false, thats the reason it was throwing Exception
Changed this to ribbon.IsSecure=true, the issue resolved
However, it would be inefficient to use route always as the traffic has to go through go-router every time.
Can you please suggest ?

[csterwa]

@dilipmighty245 at this time, SCS only supports either direct mode within a single PCF Foundation using container IP access or route mode using the Gorouter mapped route across PCF Foundations with peer replication on Service Registry.

We do have a team at Pivotal who is working on cross-foundation reference architectures that could help in this case. For instance, using NSX to create a network mesh across foundations with shared IP address space that enables connectivity. I'm sure there are other means, as well, that I'm not as well versed in. Would you mind sending a ticket into Pivotal Support to start a conversation with our internal teams who can help?

[csterwa]

Closing pending question response.