Load balancing architecture: sticky sessions and dynamic backends The Next CEO of Stack...

How to count occurrences of text in a file?

Axiom Schema vs Axiom

When you upcast Blindness/Deafness, do all targets suffer the same effect?

Why does standard notation not preserve intervals (visually)

How to check if all elements of 1 list are in the *same quantity* and in any order, in the list2?

Is it convenient to ask the journal's editor for two additional days to complete a review?

Is there a way to save my career from absolute disaster?

Would a completely good Muggle be able to use a wand?

Bartok - Syncopation (1): Meaning of notes in between Grand Staff

Domestic-to-international connection at Orlando (MCO)

How many extra stops do monopods offer for tele photographs?

Why don't programming languages automatically manage the synchronous/asynchronous problem?

Is it professional to write unrelated content in an almost-empty email?

How do I align (1) and (2)?

Does increasing your ability score affect your main stat?

Does Germany produce more waste than the US?

What was the first Unix version to run on a microcomputer?

What is the value of α and β in a triangle?

Method for adding error messages to a dictionary given a key

A Man With a Stainless Steel Endoskeleton (like The Terminator) Fighting Cloaked Aliens Only He Can See

Is wanting to ask what to write an indication that you need to change your story?

What flight has the highest ratio of time difference to flight time?

Reference request: Grassmannian and Plucker coordinates in type B, C, D

Why doesn't UK go for the same deal Japan has with EU to resolve Brexit?



Load balancing architecture: sticky sessions and dynamic backends



The Next CEO of Stack OverflowWhat is the downside to sticky sessions with load balancers?Nginx load-balancing with sessionsLoad balancing: Nginx, Varnish and HTTP sessionsnginx sticky sessions / ip_hash with Socket.ioSticky sessions on load balancers with HTTP and HTTPSLoad balance https and websockets wth sticky sessions and NGINXPound sticky sessions between HTTP and HTTPSLoad balancer F5 and sticky sessionSticky sessions with Nginx proxyLoad Balancing And Sticky Sessions












1















I'm struggling to find a solution to a specific load balancing requirement. It seems that various combinations of HAProxy, Nginx, Varnish and Apache's mod_proxy_balancer can do some but not all of what we need. My question is whether anyone can suggest a suitable configuration that would (perhaps including software that we may not have considered, but it will need to be FOSS).



The key requirement is, unfortunately, sticky sessions. We have a large, complex Tomcat app that somewhat abuses the HTTP Session, and it utilises frameworks that do the same. Converting to a stateless design or replicated session have both been investigated and discounted. Additionally, the stickiness MUST be based on a cookie and not an IP hash as we have large spikes from corporate clients where many thousands of users can all appear to be hitting the site at the same time from the same IP address.



Second most important requirement is a dynamic backend. This application runs in a cloud (not AWS) and app servers come and go from time to time based on automatic or manual scaling.



Thirdly, we need to be able to mark servers as "quiescing" so that they will continue to honour existing sessions but will not be handed new ones. When all current sessions end, the server can be turned off or upgraded/restarted.



There are some additional complications/requirements but it's meeting the three above that seems to be presenting the most difficulty.



From research so far, I think the following statements are true:




  • Nginx/Varnish can't meet the sticky session requirement (based on cookies) but HAProxy and Apache can

  • HAProxy can't do dynamic backend modification without a restart (might be ok if it's quick though). Varnish can with some VCL changes and a HUP, as could Nginx with some creative config file management I think. Apache can possibly handle this via a managed interface to mod_proxy_balancer..?

  • I'm not sure if/how any of them can deal with the third requirement


Would really appreciate any pointers or insights.










share|improve this question














bumped to the homepage by Community 10 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    1















    I'm struggling to find a solution to a specific load balancing requirement. It seems that various combinations of HAProxy, Nginx, Varnish and Apache's mod_proxy_balancer can do some but not all of what we need. My question is whether anyone can suggest a suitable configuration that would (perhaps including software that we may not have considered, but it will need to be FOSS).



    The key requirement is, unfortunately, sticky sessions. We have a large, complex Tomcat app that somewhat abuses the HTTP Session, and it utilises frameworks that do the same. Converting to a stateless design or replicated session have both been investigated and discounted. Additionally, the stickiness MUST be based on a cookie and not an IP hash as we have large spikes from corporate clients where many thousands of users can all appear to be hitting the site at the same time from the same IP address.



    Second most important requirement is a dynamic backend. This application runs in a cloud (not AWS) and app servers come and go from time to time based on automatic or manual scaling.



    Thirdly, we need to be able to mark servers as "quiescing" so that they will continue to honour existing sessions but will not be handed new ones. When all current sessions end, the server can be turned off or upgraded/restarted.



    There are some additional complications/requirements but it's meeting the three above that seems to be presenting the most difficulty.



    From research so far, I think the following statements are true:




    • Nginx/Varnish can't meet the sticky session requirement (based on cookies) but HAProxy and Apache can

    • HAProxy can't do dynamic backend modification without a restart (might be ok if it's quick though). Varnish can with some VCL changes and a HUP, as could Nginx with some creative config file management I think. Apache can possibly handle this via a managed interface to mod_proxy_balancer..?

    • I'm not sure if/how any of them can deal with the third requirement


    Would really appreciate any pointers or insights.










    share|improve this question














    bumped to the homepage by Community 10 mins ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      1












      1








      1


      1






      I'm struggling to find a solution to a specific load balancing requirement. It seems that various combinations of HAProxy, Nginx, Varnish and Apache's mod_proxy_balancer can do some but not all of what we need. My question is whether anyone can suggest a suitable configuration that would (perhaps including software that we may not have considered, but it will need to be FOSS).



      The key requirement is, unfortunately, sticky sessions. We have a large, complex Tomcat app that somewhat abuses the HTTP Session, and it utilises frameworks that do the same. Converting to a stateless design or replicated session have both been investigated and discounted. Additionally, the stickiness MUST be based on a cookie and not an IP hash as we have large spikes from corporate clients where many thousands of users can all appear to be hitting the site at the same time from the same IP address.



      Second most important requirement is a dynamic backend. This application runs in a cloud (not AWS) and app servers come and go from time to time based on automatic or manual scaling.



      Thirdly, we need to be able to mark servers as "quiescing" so that they will continue to honour existing sessions but will not be handed new ones. When all current sessions end, the server can be turned off or upgraded/restarted.



      There are some additional complications/requirements but it's meeting the three above that seems to be presenting the most difficulty.



      From research so far, I think the following statements are true:




      • Nginx/Varnish can't meet the sticky session requirement (based on cookies) but HAProxy and Apache can

      • HAProxy can't do dynamic backend modification without a restart (might be ok if it's quick though). Varnish can with some VCL changes and a HUP, as could Nginx with some creative config file management I think. Apache can possibly handle this via a managed interface to mod_proxy_balancer..?

      • I'm not sure if/how any of them can deal with the third requirement


      Would really appreciate any pointers or insights.










      share|improve this question














      I'm struggling to find a solution to a specific load balancing requirement. It seems that various combinations of HAProxy, Nginx, Varnish and Apache's mod_proxy_balancer can do some but not all of what we need. My question is whether anyone can suggest a suitable configuration that would (perhaps including software that we may not have considered, but it will need to be FOSS).



      The key requirement is, unfortunately, sticky sessions. We have a large, complex Tomcat app that somewhat abuses the HTTP Session, and it utilises frameworks that do the same. Converting to a stateless design or replicated session have both been investigated and discounted. Additionally, the stickiness MUST be based on a cookie and not an IP hash as we have large spikes from corporate clients where many thousands of users can all appear to be hitting the site at the same time from the same IP address.



      Second most important requirement is a dynamic backend. This application runs in a cloud (not AWS) and app servers come and go from time to time based on automatic or manual scaling.



      Thirdly, we need to be able to mark servers as "quiescing" so that they will continue to honour existing sessions but will not be handed new ones. When all current sessions end, the server can be turned off or upgraded/restarted.



      There are some additional complications/requirements but it's meeting the three above that seems to be presenting the most difficulty.



      From research so far, I think the following statements are true:




      • Nginx/Varnish can't meet the sticky session requirement (based on cookies) but HAProxy and Apache can

      • HAProxy can't do dynamic backend modification without a restart (might be ok if it's quick though). Varnish can with some VCL changes and a HUP, as could Nginx with some creative config file management I think. Apache can possibly handle this via a managed interface to mod_proxy_balancer..?

      • I'm not sure if/how any of them can deal with the third requirement


      Would really appreciate any pointers or insights.







      linux load-balancing cloud






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 18 '14 at 21:05









      darrenddarrend

      1212




      1212





      bumped to the homepage by Community 10 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 10 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          1 Answer
          1






          active

          oldest

          votes


















          0














          With HAProxy you can add the whole range of possible backend servers and then turn them on and off (hard or soft) using the admin pages/socket calls.



          How does that not fit your requirements?






          share|improve this answer
























          • Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

            – darrend
            Jan 19 '14 at 10:15











          • hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

            – JamesRyan
            Jan 19 '14 at 13:16











          • If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

            – darrend
            Jan 19 '14 at 16:46












          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "2"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f568253%2fload-balancing-architecture-sticky-sessions-and-dynamic-backends%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          With HAProxy you can add the whole range of possible backend servers and then turn them on and off (hard or soft) using the admin pages/socket calls.



          How does that not fit your requirements?






          share|improve this answer
























          • Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

            – darrend
            Jan 19 '14 at 10:15











          • hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

            – JamesRyan
            Jan 19 '14 at 13:16











          • If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

            – darrend
            Jan 19 '14 at 16:46
















          0














          With HAProxy you can add the whole range of possible backend servers and then turn them on and off (hard or soft) using the admin pages/socket calls.



          How does that not fit your requirements?






          share|improve this answer
























          • Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

            – darrend
            Jan 19 '14 at 10:15











          • hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

            – JamesRyan
            Jan 19 '14 at 13:16











          • If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

            – darrend
            Jan 19 '14 at 16:46














          0












          0








          0







          With HAProxy you can add the whole range of possible backend servers and then turn them on and off (hard or soft) using the admin pages/socket calls.



          How does that not fit your requirements?






          share|improve this answer













          With HAProxy you can add the whole range of possible backend servers and then turn them on and off (hard or soft) using the admin pages/socket calls.



          How does that not fit your requirements?







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 19 '14 at 2:12









          JamesRyanJamesRyan

          7,78322036




          7,78322036













          • Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

            – darrend
            Jan 19 '14 at 10:15











          • hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

            – JamesRyan
            Jan 19 '14 at 13:16











          • If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

            – darrend
            Jan 19 '14 at 16:46



















          • Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

            – darrend
            Jan 19 '14 at 10:15











          • hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

            – JamesRyan
            Jan 19 '14 at 13:16











          • If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

            – darrend
            Jan 19 '14 at 16:46

















          Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

          – darrend
          Jan 19 '14 at 10:15





          Servers brought online will get a DHCP address from a /24, so adding 256 addresses as backends with about 250 disabled most of the time was not the most obvious thing to think of. There was also no description of whether disabling servers allows them to receive requests with valid persistence cookies here, which I had already read: cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 I have now found it elsewhere in the docs, so yes, looks like it would be an option.. I'll try it over the next day or so. Thx.

          – darrend
          Jan 19 '14 at 10:15













          hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

          – JamesRyan
          Jan 19 '14 at 13:16





          hrm yeah, that does sound a bit unmanageable. No way you can narrow the range to what you expect to scale to?

          – JamesRyan
          Jan 19 '14 at 13:16













          If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

          – darrend
          Jan 19 '14 at 16:46





          If it looks viable in all other respects, then yes, I can create a smaller address pool and ensure that our cloud API calls are aware of how to choose a pool when creating a new server.

          – darrend
          Jan 19 '14 at 16:46


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Server Fault!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f568253%2fload-balancing-architecture-sticky-sessions-and-dynamic-backends%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          As a Security Precaution, the user account has been locked The Next CEO of Stack OverflowMS...

          Список ссавців Італії Природоохоронні статуси | Список |...

          Українські прізвища Зміст Історичні відомості |...