Results 1 to 8 of 8
  1. #1
    Join Date
    Jun 2007
    Location
    Tokyo, Japan
    Posts
    336

    Server Clustering Help

    Hello,
    I am trying to setup a server cluster for my client and was thinking about load balancer.
    Currently he has 4 Servers and 1 VPS.
    4 Servers are in the same datacenter while VPS isn't.
    Now from my thoughts about the system load, I have decided to setup like this:
    VPS being the load balancer
    2 Servers being the Apache
    1 Server being Storage server
    1 Server being MySQL
    This will be hosting two forums that has very high concurrent access.
    Now the problem is VPS has only 200GB/mo bandwidth while he needs about 800GB total.
    My question is is there anyway to load balance the servers without the traffic going like this:
    LoadBalancer-->Apache Servers-->LoadBalancer-->USER
    If the traffic goes like that then VPS needs to have about 1600GB bandwidth and will have network bottlenecks.
    I would like the traffic to go like the following:
    LoadBalancer-->Apache Servers-->USERS
    Thanks for your help,
    Yudai Yamagishi
    Yudai Yamagishi

  2. #2
    Join Date
    Dec 2006
    Posts
    4,151
    DNS Roundrobin connects users directly to Apache Servers, not to the loadbalancer.

  3. #3
    Join Date
    Apr 2003
    Location
    Melbourne, AU
    Posts
    539
    "LoadBalancer-->Apache Servers-->USERS" is possible with LVS tunneling, but I think it's unnecessary. As tsj5j said, you can simply direct the users to the Apache servers with DNS Roundrobin. This way, you cut away the VPS from being a single point of failure.

    (If you do go that way though, I recommend that you use a lightweight frontend httpd such as nginx or lighttpd)
    WK Woon
    CTO | http://www.aflexi.net - A flexible Network
    Building the next generation CDN platform - DEMO .... coming soon

  4. #4
    Join Date
    Jun 2007
    Location
    Tokyo, Japan
    Posts
    336
    The problem with DNS round robin is is that some ISPs cache DNS records and everyone using those ISP uses the server that ISP cached.
    Another problem is, if I need to do maintainance on one of the nodes, people who gets that node's IP from DNS server will get unresponsive node so.
    Also, there is a possibility of load concentrating on to one of the servers so I don't wish to use DNS Round Robin.
    Yudai Yamagishi

  5. #5
    Join Date
    Apr 2003
    Location
    Melbourne, AU
    Posts
    539
    But you see, the same problem happens if you opt for the VPS way. If you wish to take the VPS down for maintenance, you lose *all* your traffic.

    It is much more managable if you do go the DNS RR way. Presuming the Apache boxes are in the same ethernet segment, just assign them two IPs each - one for management, and another "floating" IP where the public services listen on. When you wish to take one server down for maintenance, unconfigure the floating IP from it and add it to the other. It's a textbook HA technique

    You are right when you say that there is a possibility for load hotspots to form. In practice though, I didn't notice much deviation. And anyway, it can be managed through the use of a HTTP balancer at the Apache boxes.
    WK Woon
    CTO | http://www.aflexi.net - A flexible Network
    Building the next generation CDN platform - DEMO .... coming soon

  6. #6
    Join Date
    Jun 2007
    Location
    Tokyo, Japan
    Posts
    336
    I just contacted the server provider and told me that internal traffic isn't counted to the traffic allocation so I think my client should get another low end dedicated server and put Apache with mod_proxy or something.
    What would you suggest on this case?
    Load balancer being LVS? Apache mod_proxy? nginx's weight load balancing feature? etc.
    Yudai Yamagishi

  7. #7
    Join Date
    Aug 2007
    Posts
    57
    The "load balanced" scenario you're describing is going to be sub-optimal, and probably not worth the expense. In short, you're probably not going to see much gain in performance.

    DNS RR is fine, unless the application is "session sensitive", and needs to talk to one web server the entire time; if the session data is stored in the db, then this is not a problem, but if it's stored, say, in /tmp by PHP in sess_ files, then when they go between server 1 and server 2, e.g. their cart will alternate between being empty and having items.


    As to your assumptions about DNS caching, well, no, not really. Try 'ping www.google.com' and run that a few times, see the differences in results? There's two types of DNS Round Robin load balancing; one is the standard method, where there's just several IP's for a single name, which are all offered when someone asks what www.google.com is.

    The second is the Akami-style, where depending where you are in the world, it gives a single answer for the name (geoDNS). The second is out of reach for most people, the first, however, is very effective.

    I'm not sure how you're reaching the assumption that this would be "internal traffic" on the VPS; if the VPS is in a different datacenter, then this would be external traffic. Not only that, but given that it's in a different datacenter, you'd be incurring a huge amount of latency from the network transit alone, let alone the fact that you're going to pummel the VPS and quickly discover why this is an incredibly bad idea.

    In short, either do DNS Round Robin, or rearchitect your idea of how to load balance this. Determine where the load is actually occurring; you should have ONE front-end web server that has very light load, and handles ALL the connections, and that server uses multiple back-end servers. E.g. if MySQL can't keep up with the reads, use one server as a read/write master, and another server (or three) as slaves, and direct read-only queries to the slaves, while writes go to the master.

    If you have to go with multiple front-end servers, start looking at an F5 BigIP. If you can't afford an F5 suitable for the scenario, you should evaluate the cost of rearchitecting to eliminate the requirement for multiple front-end servers.

    Please understand, I'm not knocking your idea because it's "low tech", I'm simply telling you that it's going to be an extremely inefficient way of doing things, will not scale, may degrade performance, and will cost you time and money than it's worth.

  8. #8
    Join Date
    Jun 2007
    Location
    Tokyo, Japan
    Posts
    336
    Quote Originally Posted by macker View Post
    The "load balanced" scenario you're describing is going to be sub-optimal, and probably not worth the expense. In short, you're probably not going to see much gain in performance.

    DNS RR is fine, unless the application is "session sensitive", and needs to talk to one web server the entire time; if the session data is stored in the db, then this is not a problem, but if it's stored, say, in /tmp by PHP in sess_ files, then when they go between server 1 and server 2, e.g. their cart will alternate between being empty and having items.


    As to your assumptions about DNS caching, well, no, not really. Try 'ping www.google.com' and run that a few times, see the differences in results? There's two types of DNS Round Robin load balancing; one is the standard method, where there's just several IP's for a single name, which are all offered when someone asks what www.google.com is.

    The second is the Akami-style, where depending where you are in the world, it gives a single answer for the name (geoDNS). The second is out of reach for most people, the first, however, is very effective.

    I'm not sure how you're reaching the assumption that this would be "internal traffic" on the VPS; if the VPS is in a different datacenter, then this would be external traffic. Not only that, but given that it's in a different datacenter, you'd be incurring a huge amount of latency from the network transit alone, let alone the fact that you're going to pummel the VPS and quickly discover why this is an incredibly bad idea.

    In short, either do DNS Round Robin, or rearchitect your idea of how to load balance this. Determine where the load is actually occurring; you should have ONE front-end web server that has very light load, and handles ALL the connections, and that server uses multiple back-end servers. E.g. if MySQL can't keep up with the reads, use one server as a read/write master, and another server (or three) as slaves, and direct read-only queries to the slaves, while writes go to the master.

    If you have to go with multiple front-end servers, start looking at an F5 BigIP. If you can't afford an F5 suitable for the scenario, you should evaluate the cost of rearchitecting to eliminate the requirement for multiple front-end servers.

    Please understand, I'm not knocking your idea because it's "low tech", I'm simply telling you that it's going to be an extremely inefficient way of doing things, will not scale, may degrade performance, and will cost you time and money than it's worth.
    Hmm...
    I have two customer here needing a server load balancing.
    One of them who needs a DirectAdmin, I figured that one out.
    For DirectAdmin Customer I can put nginx and load balance the FastCGI and MySQL.
    (Idea provided by tsj5j. Thanks tsj5j)

    Maybe I can do that on this customer too?
    Front web server (nginx) and load balance the FastCGI between two servers.
    MySQL can be load balanced as well if I do that since I will not be needing a storage server then.
    Yudai Yamagishi

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •