Forum Discussion

David_Larsen's avatar
David_Larsen
Icon for Employee rankEmployee
Jul 28, 2009

Distributed management servers architecture

According to m$ best practices in OpsManager 2007 as I understand, the secondary management servers should never have the Console or management packs directly installed to them. With the F5 management pack we seem to be breaking both of these standards, by first installing the management pack on each server and then installing the console on the secondary management servers.

 

 

Can someone explain why doing it this way is better? The console, no matter where it is installed, always talks back to the RMS server. In the tutorials and the doco it looks as if the secondary management server instances are talking to the RMS for everything except the F5 management pack. What are the best practices for handling this and making the management of not only the F5 devices but other devices scalable to an enterprise? I am concerned that there is no failover of management servers if one of them dies then i have to rediscover the F5 from another management server.

 

 

The second question is the F5 devices don't show in the device listings for Operations Manager. I would have thought they would be targeted as network devices into the device list or agentless managed.

 

 

Thanks for the clarifications.
management
microsoft
scom

2 Replies

Sort By
  • Dave_Ruddell_79's avatar
    Dave_Ruddell_79
    Historic F5 Account
    Jul 28, 2009
    You are correct in regard to best practices. It is best practice to install the management pack only onto the RMS and not the secondary management servers. We actually follow 'best practices' and have been working closely with the Operations Manager team in order to provide the best performance out of our management pack software suite as well as the hardware it runs on. I will give you a run-down of how our management pack installs as well as how very different it is from a typical 3rd party management pack.

     

     

    First of all, our installation package not only includes the management pack file (F5_ManagementPack.mp), but also a Windows service and a collection of libraries and modules which are used to communicate with the F5 devices (Big-IP, etc). The service is necessary because we use a custom protocol to communicate with our F5 devices, which Operations Manager does not currently support. This protocol is something written by F5 and extremely fast and lightweight compared to SNMP. We also have DataSource modules, which are loaded directly into the Operations Manager Health Service, and provides direct communication with the RMS and Operations Manager databases in most cases.

     

     

    As far as installation is concerned, we only import the actual management pack file onto the RMS, which is why it is required that you install it there first. It is then required to install it onto the secondary management servers because our service and modules are required to actually discover and monitor our F5 devices. This provides the maximum throughput for health and statistics to be collected from the F5 devices.

     

     

    Concerning scalability, we currently do not have fail-over support, but it is definitely in the road-map for our product. So unfortunately for now, you would have to rediscover the F5 device from another management server.

     

     

    Lastly, the F5 devices don't show up in the device listings under the Operations Manager group because we have created our own group and sub-groups which help better organize our devices with other devices discovered on the network.

     

     

    I hope this clarifies things a bit better for you. Let me know if any of this doesn't make sense.

     

     

    Thanks,

     

    -Dave

     

     

     

  • David_23288's avatar
    David_23288
    Icon for Nimbostratus rankNimbostratus
    Jul 29, 2009
    Thank you for all the clarification. Now I understand your design much better. This brings up another question. It appears the only thing you really have to do from the secondary managment servers is discovery and deletion of the F5 devices. During the discovery process I see the powershell commands to recreate discover so I can run a discovery on the secondary management server without the operations console. Is there an equivalent command to remove an F5 device using powershell.

     

    This way I do not have to install the operations console on my secondary server which we have a strict policy on. Is there any other things I can only do from the management server the device was discovered on?

     

    thanks for all the support.
Related Content