> From: Joegen Baclor [[email protected]] > > I am implementing an RLS service that shares load via DNS/SRV records. > Let us say I have 2 RLS servers sharing the load equally for 200 > subscribers. In an ideal setting, each would service 100 subscribers > each. In the moment one goes down, subscribers from the other server > spills over to the other server. So at one point all 200 subscribers > are now subscribed to a single server. When the node that went down > previously goes up, I like to be able to bring back load sharing between > the two nodes. There seems to be no obvious mechanism to do this in > SIP. I would appreciate some insights and suggestions.
There are at least two approaches. One approach is to have the RLS servers split the load on a request-by-request basis, so that they are jointly the notifyer UA for the subscriptions. This requires that they share all of the subscription state. When a server sends the 200 to a subscription-initiating SUBSCRIBE, it inserts a Record-Route containing a DNS name that resolves to both servers. Thus, each SUBSCRIBE within the dialogs goes randomly to either of the servers, and the server that receives the SUBSCRIBE replicates the updated subscription state to the other server. For any NOTIFY to be generated, the servers have to decide which of them is to send it, and update their mutually-held subscription state to record that fact. This would be rather high-overhead to implement. Another approach is to have both servers serve the same data, but any single subscription is terminated on only one server as notifying UA. If one server goes down, when a UA whose subscription is notified by that server decides to re-SUBSCRIBE, it discovers the server is down. The UA reestablishes a new subscription, which goes to the other server. When the down server comes up again, the load is unbalanced. The overloaded server could force some subscriptions to be reestablished by sending "NOTIFY/Subscription-State: terminated". But I don't think there's any point in doing that -- of necessity, either server must be able to handle the full load without degrading the system. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
