5 Replies Latest reply on Jun 29, 2009 3:56 PM by zman

    How Many Core Servers Do You Need......?

    Apprentice

      We have 14,000 nodes and 1 core server.

       

      It is a pretty delicately balanced affair, that requires fairly frequent tweaking (IIS/LD/OS) depending on the loads from the different tasks being undertaken.

       

       

      1.  Would this task be easier with the load spread over more core servers, or would the tasks of maintaining more boxes cancel that out?

       

      2.  What nodes to core server ratios are people running, and would they recommend them?

       

       

      Cheers all.

        • 1. Re: How Many Core Servers Do You Need......?
          phoffmann SupportEmployee

          "It depends" is - as so often - the key phrase here. Mainly, it depends on what you're wanting to do / what's important to you in which order.

           

          I'd suggest sitting down and making a list of priorities for what matters to you the most - that'll factor in heavily. I'll try to include reasons for/against both approaches that are frequently encountered in this sort of decision making .

           

          "Single Core - positives"

           

          * You have a very "easy" (-ish) to manage access to ALL your clients.

          * If you need to roll out a new policy / package, you don't need to worry about replicating / queries / etc.

          * Single server (well - plus the DB backend) to look after / monitor / tune ... all easily reachable if needed.

           

          * Single point of reporting, valid for all data - SLM, Patch Management and all other reports too. HOWEVER ... whether a report on "the entire environment" will be able to run, depends on a couple of factors. Running a "show me all files on all of my 20,000 devices"-style report is likely to time out several times over in multiple regards.

           

           

          "Single Core - negatives"

           

          * Potential single point of failure. If your Core goes down, things rely on how healthy your backup strategy is (some people still don't have one). Though a standby server here will often be sufficient to offset the risk.

           

          * Potential organisational nightmare ... depending on how much of a bureaucratic/political nightmare an organisation is, having a single point of control may or may not even be acceptable to other site admins. It can get pretty political, especially if they want/demand certain autonomy about their area of control.

           

          * WAN links may be a factor. While the Core won't be heavily affected by its link to the (I'd imagine / hope) nearby DB-server, the remote 32-bit consoles might have to jump through quite a few WAN-hoops to get there, making them slower. Using WebConsoles may be a sufficient counter here (it depends - can't manage patches through WebConsole yet).

           

          * Potentially MASSIVE hardware requirements. The more the Core is used, the more resources (mostly hardware) the Core + the DB-server will gobble up. Traditionally, prices for this tend to go up exponentially ... i.e. a single quad physical CPU server would cost more than 2x dual CPU servers.

           

          ===========

           

          "Multi Core - positives"

           

          *Spread out points of failure - if a Core goes down, you've not lost LD-granted power over your entire organisation. At a push (assuming you've exchanged certs), you can even manage some things for the Core that's gone down. Not everything, but "some" at least.

           

          - This is OFTEN used to split up countries and/or entire GEO's (i.e. 1 server for EMEA, 1 for APAC, 1 for NAMO), or even organisational structures (1 Core for the desktop world, one for the server world) - can help make this a LOT more manageable.

           

          - Allows to split up the hardware requirements quite a bit.

           

          "Multi Core - negatives"

           

          * You may have to work on replicating distribution packages between the Cores (unless you use a rollup to run the show, see below).

          * You may have to work on replicating queries between the Cores (unless you use a rollup to run the show, see below). LD-methods exist for LD-quieries. AD-queries cannot be exported/replicated automatically

           

          * Tasks need to be replicated. While (some kinds of) queries and packages CAN be replicated, entire tasks CAN NOT.

          * Potentially, considerably more servers to look after / monitor / tune ... may not be easily accessed from central side.

           

          * No single point of reporting, except for a rollup. Depending on how important reporting is for you, this is going to be a bigger or smaller issue.

           

          ===========

           

          Multi Cores ++ Rollup to "run the show":

           

          +/- Single-ish point of reporting. Some reports WILL not be rolled up, because they're simply seen as blowing a rollup up. This is mainly affecting SLM and Patch-related information.

           

          NOTE - this MAY change with Pikes Peak, I don't know. I know a fair bit of of work is being done towards making things more enterprise friendly. Keep an eye out.

           

          + You *CAN* run an entire organisation centrally from a rollup. Rollups can delegate (automatically) software distribution tasks to the relevant Cores hosting the clients. These tasks do NOT (!) show up in the Core's UI, but do show up in the DB (and are run by the Core). I know of a few that do.

           

          Essentially, think of the Rollup as "el generalissimo" ordering about its minion cores.

           

          +/- A rollup Core is still going to be quite resource hungry. Not as bad as a "live" Core (on account of not being beaten to death by IIS for the most part), but it's not exactly "light going" either... there's quite a few things for it to do. And of course the DB is still massive.

           

          +/- You need to identify time-windows when we can sync up data ... the Rollup needs to (effectively, I'm simplifying somewhat) to copy each Core's DB into itself at regular intervals. Whether or not the WAN links can cope with that may also be an issue.

           

           

          ==============

           

          That's a few starting points. There's more things I'm sure, but at the moment my brain is somewhat melting away in the heat, so I'll try and have a look to add more things when it cools down some. *Fingers crossed*.

           

          But in short, it's not "as simple as it seems" ... and there's some VERY interesting features potentially in this sort of regard planned for Pikes Peak that may help you out as well. So for details, you may want to get in touch with your LANDesk rep / technical consultants.

           

          - Paul Hoffmann

          LANDesk EMEA Technical Lead

          • 2. Re: How Many Core Servers Do You Need......?
            phoffmann SupportEmployee

            In regards to "ratio" ... we usually recommend a soft limit of 10,000 clients to one Core. That's usually the "cut off point" where you need to start throwing some very serious hardware against the Core.

             

            In particular IIS is the main problem child here, and anyone who isn't using patch management (yet) has a big relief here. Patch Management has a lot to talk about through IIS, and IIS is very resource intensive.

             

            The recommendations for the # of nodes versus hardware in this document are all "real world" experience based, from us and observations of "what works / what does not" at customers:

             

             

            http://community.landesk.com/support/docs/DOC-2356

             

            If you use the "heavy I/O hitters" - mainly inventory + patch manager reasonably frequently, then a single Core may get quite a tonne of work to do. Another question to put the pressure off your servers might be revising this and finding out "do I really need to do this the way I do?"

             

            I.e. - IIS is going to have a LOT more to struggle if it has to cope with 14,000 requests coming in over a single hour. Particularly if during that same time, the inventory service is getting 14,000 inventory scans to cope with (hello logon wave).

             

            Using the local scheduler, you can split this out ... for instance, something like this:

             

            ** Accounting - 1,000 nodes -- inventory + vulscan from 03:00 - 04:00

            ** Kitchen - 500 nodes -- inventory + vulscan from 04:00 - 05:00

            ** Writers - 2000 nodes -- inventory + vulscan from 05:00 -- 07:00

             

            and so on.

             

            By carefully redesigning what comes in when, you can make quite a difference on your server ...

             

            - Paul Hoffmann

            LANDesk EMEA Technical Lead

            • 3. Re: How Many Core Servers Do You Need......?
              Apprentice

              lol!!!

               

              Do you get paid by the word Paul!!!

               

              Very detailed - much appreciated, i will have a read through later today hopefully.

              • 4. Re: How Many Core Servers Do You Need......?
                phoffmann SupportEmployee

                Regrettably no.

                 

                This has mainly to do with my intention of being lazy - i.e. - if I write down something properly once, then the (naive) hope is that I can point any future recurrences of similar questions back to this post / thread .

                 

                My idealism still survives somehow .

                 

                - Paul Hoffmann

                LANDesk EMEA Technical Lead

                • 5. Re: How Many Core Servers Do You Need......?
                  zman Master

                  That's what happens when he takes a break, he gets a second wind

                   

                  Also, from a multi core managment standpoint (replication and such) this will be getting a lot easier in the near future.  So with a new version just around the corner somewhat, If this is not a critical issue, I would hold off evaluating until the end of the year.