- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-17-2017 01:31 PM
Hi All,
We set up MID servers for each network segment in load-balanced pairs (MID Server Cluster)
When I do Discovery, I can choose the behavior to use a cluster, specific MID Server etc which is awesome.
I recently needed to set up an Export Set to send a csv file to a specific MID server, but that MID server belongs to a load-balanced cluster. The result is sometimes the file gets sent to the MID server I want, but sometimes it goes to the other MID server.
Is there a way to configure Export Sets to use a specific MID server and not the cluster as in Discovery?
Thanks,
Jeff
Solved! Go to Solution.
- Labels:
-
Orchestration
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-18-2017 01:19 AM
The export just creates an ecc_queue output record for the export, and lets the business rule "MID Server Cluster Management" load-balance the record however he likes.
What if you wrote a business rule that runs before "MID Server Cluster Management" to detect export records and force the mid server?
If you look at the "MID Server Cluster Management," you can see he scans the payload with a regex to see if the loadbalancing has already been handled in the improved-in-Istanbul SncProbe load balancing. That regex is off in Java somewhere, as is SncProbe, so we can't directly see the format of the load balancing params.
What we can do is call SncProbe to force a probe to a mid server, and then see what the ecc_queue format looks like.
This background script creates and runs about the simplest probe possible, forcing the mid not to be load-balanced.
var probe = new SncProbe();
probe.setTopic('HeartbeatProbe');
probe.createForMidServer('myMidServer', null);
When I run it, go to the ecc_queue, (and clear out the filter that screens out HeartBeats), I see this in the payload of the ecc_queue output record:
<?xml version="1.0" encoding="UTF-8"?><parameters><parameter name="mid_selector_details" value="{"mode":"specific_mid"}"/></parameters>
That mid_selector_details parameter appears to be the secret sauce.
If you had a business rule that fired on ecc_queue insertion, with order picked to prioritize it above "MID Server Cluster Management," ran it on insertion of export outputs, and added this parameter to the payload, it should cause the load balancing to be bypassed.
This isn't documented behavior - we're mimicking how the java currently talks to the ecc_queue, and there is no real promise that it will work that way for >= London.
That's the cleanest way I can think of. Every other crazy idea I can think of:
- Having a dummy record in your table that contains this parameter, but that's really cheesy.
- Marking the other mid down before exporting and bringing it back up after.
- Keep exporting until it gets to the right mid.
- If it goes to the wrong mid, SCPRelay it to the other one. ...or just always do SCPRelay and let it fail if it went to the right one.
- Don't cluster the export mid.
- Custom capabilities? I don't have time to try this, but the business rule uses the MIDServerCluster script include to do the load balancing. In MIDServerCluster._phase2(), he appears to only take mids whose capabilities are a superset of the original mid's. So, if you added some capability to the export mid that is not on the other mid in the cluster, I think the traffic would not get load-balanced. This would mean you would need to specify the other mid server when you do want the traffic to get load-balanced. You could use an existing capability, or just make up a new one.
Actually, #6 doesn't seem so bad, now that I look at it.
Hope some piece of this brain dump is helpful to you,
- Tim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-17-2017 10:59 PM
Hi Jeff
In past i also faced the similar kind of the issue when i was doing the JDBC connection using MidServer. Whenever i was using one of the clustered MIDServer, i was getting the issue but it was intermittent and at that time I was in Fuji release.Servicenow support also identified this issue at that time and they had a problem ticket. I do not have that handy right now.
I will suggest to use the MIDServer which is not part of cluster.I think this will resolve your issue.
Regards,
Harsh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-18-2017 01:19 AM
The export just creates an ecc_queue output record for the export, and lets the business rule "MID Server Cluster Management" load-balance the record however he likes.
What if you wrote a business rule that runs before "MID Server Cluster Management" to detect export records and force the mid server?
If you look at the "MID Server Cluster Management," you can see he scans the payload with a regex to see if the loadbalancing has already been handled in the improved-in-Istanbul SncProbe load balancing. That regex is off in Java somewhere, as is SncProbe, so we can't directly see the format of the load balancing params.
What we can do is call SncProbe to force a probe to a mid server, and then see what the ecc_queue format looks like.
This background script creates and runs about the simplest probe possible, forcing the mid not to be load-balanced.
var probe = new SncProbe();
probe.setTopic('HeartbeatProbe');
probe.createForMidServer('myMidServer', null);
When I run it, go to the ecc_queue, (and clear out the filter that screens out HeartBeats), I see this in the payload of the ecc_queue output record:
<?xml version="1.0" encoding="UTF-8"?><parameters><parameter name="mid_selector_details" value="{"mode":"specific_mid"}"/></parameters>
That mid_selector_details parameter appears to be the secret sauce.
If you had a business rule that fired on ecc_queue insertion, with order picked to prioritize it above "MID Server Cluster Management," ran it on insertion of export outputs, and added this parameter to the payload, it should cause the load balancing to be bypassed.
This isn't documented behavior - we're mimicking how the java currently talks to the ecc_queue, and there is no real promise that it will work that way for >= London.
That's the cleanest way I can think of. Every other crazy idea I can think of:
- Having a dummy record in your table that contains this parameter, but that's really cheesy.
- Marking the other mid down before exporting and bringing it back up after.
- Keep exporting until it gets to the right mid.
- If it goes to the wrong mid, SCPRelay it to the other one. ...or just always do SCPRelay and let it fail if it went to the right one.
- Don't cluster the export mid.
- Custom capabilities? I don't have time to try this, but the business rule uses the MIDServerCluster script include to do the load balancing. In MIDServerCluster._phase2(), he appears to only take mids whose capabilities are a superset of the original mid's. So, if you added some capability to the export mid that is not on the other mid in the cluster, I think the traffic would not get load-balanced. This would mean you would need to specify the other mid server when you do want the traffic to get load-balanced. You could use an existing capability, or just make up a new one.
Actually, #6 doesn't seem so bad, now that I look at it.
Hope some piece of this brain dump is helpful to you,
- Tim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2017 10:48 AM
Thanks Tim!
I went with the path of least resistance and just set up a single, non-clustered MID server. One of those cases where it needed to be done "ASAP".
I think I will check out some of the solutions you mentioned and see what happens in a sub-prod instance.
Thanks,
Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-30-2017 11:56 AM
Simple is good.