5 Replies Latest reply on Dec 15, 2009 8:05 AM by Sk1dMARK

    epo 4.5 and DRP

    jj4sec

      We have 2 primary and 2 backup datacenters and 60.000 hosts.

      Does someone has experiance with a DRP design with EPO ?

      Should I use 2 EPO servers or only one and use agent handlers for backup ?

      In a DRP situation I want my EPO + SQL server up and running as soon as possible. How should I make my design.  I have the idee that when I work with 2 EPO servers and one shoud crash, the second one will not handle my hosts.  Is this correct ?

        • 1. Re: epo 4.5 and DRP
          jstanley

          The best solution here would be to install both ePO 4.5 and SQL on a cluster. If you are managing 60,000 clients then I would recommend a dedicated EPO server and a separate SQL server.

           

          Agent handlers can provide backup for agent-to-server communication so long as the SQL server does not also go down; however, if the EPO server is hard down agent handlers will not be able to distribute DAT updates (because they must be able to pull the updates from the EPO server's master repository). Also agent handlers do not host the console so if your EPO server is down you will not be able to access the EPO console.

           

          Indeed if you have 2 seperate EPO servers and one goes down agents will not know to start communicating with a different EPO server.

           

          If you cannot use a cluster then the DRP for EPO 4.5 is covered in KB66616:

          https://kc.mcafee.com/corporate/index?page=content&id=KB66616

          • 2. Re: epo 4.5 and DRP
            devilson911

            Thanks

            • 3. Re: epo 4.5 and DRP
              Sk1dMARK

              Just thinking out loud here, but couldn't you achieve this with doing the following (and likely more steps, but just throwing this out there):

               

              -use 2 ePO servers with identical configs (system tree, tasks, etc...) (one would be a pseudo-master server that you would console into regularly)
              -register each server to each other
              -use policy sharing so that changes to policy only need to be made at the main server
              -use multi-server rollup querying
              -schedule the Transfer Systems task to run daily or weekly or something.

               

              With some tweaks to the above and with more detail and likely more steps involved, I was thinking that you could have a DRP solution.

               

              Your client machines would transfer themselves back and forth daily/weekly/whatever on their own between the 2 ePO servers, but it wouldn't matter where they are (which ePO server they are reporting to) as the rollup reporting and querying would handle the needs.

               

              Regards,

               

              Mark

               

              P.S.  I should have prefaced this by saying that I am still running ePO 3.6.1, but am very curious about a DRP solution as I am in a similar situation to the OP and moving to ePO 4.5 very soon with a DRP need that 3.6.1 did not afford me.

               

              P.S.S. If anyone can expand on this to create a workable/more workable solution, please contribute.

              • 4. Re: epo 4.5 and DRP
                jstanley

                For the transfer agents option to work the client must be able to connect to it's original EPO server which then provides the sitelist.xml for the new server so it would not be helpful for DR.

                 

                I'm afraid clustering or KB66616 will be the only real options but feel free to keep posting alternate methods perhaps I'm wrong.

                 

                 

                Message was edited by: Jeremy Stanley on 12/14/09 5:02:44 PM CST
                • 5. Re: epo 4.5 and DRP
                  Sk1dMARK

                  I see an FMR in my future.

                   

                  Time to get the Platinum SAM on the horn.

                   

                   

                  Thanks for your input on this.  It is appreciated.

                   

                   

                  Mark