SUSE Manager/Sizing Scaling

From MicroFocusInternationalWiki
Revision as of 20:18, 21 July 2011 by Kwk (Talk | contribs) (Created page with "<h1>SUSE Manager - Sizing and Scaling</h1> From === Clustering === I heard that somebody deploy it as active:pasive (not sure if I follow some clu...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

SUSE Manager - Sizing and Scaling



 I heard that somebody deploy it as active:pasive (not
 sure if I follow some cluster terminology) - i.e. one spacewalk as
 active server and another as backup, which can be hot-swapped in case
 the first one die.
 But if you use one OracleDB and one storage shared by both Spacewalk
 server and do rhnpush/spacewalk-repo-sync task only on one of the server
 at the same time, you can have luck. But you will be alone in deep
 space. But I will be waiting for your report.


 If you want just load balance it across more HW and locations, it is
 much better and simple solution to use one or more Spacewalk Proxies in
 front of Spacewalk Server. Spacewalk Server can handle more then 30,000
 machines for sure. But we recommend to use One Spacewalk Proxy per each
 5,000 server to offload some traffic from Spacewalk Server.

Database Sizing

From RHN Satellite documentation

A single 6 GB tablespace is recommended as more than sufficient for most installations. It is possible for many customers to function with a smaller tablespace. An experienced Oracle database administrator (DBA) will be necessary to assess sizing issues. The following formula should be used to determine the required size of your database:

  • 192 KB per client system
  • 64 MB per channel

Keep in mind, the database storage needs may grow rapidly, depending upon the variance of the following factors:

  • The number of public Vendor packages imported (typical: 5000)
  • The number of private packages to be managed (typical: 500)
  • The number of systems to be managed (typical: 1000)
  • The number of packages installed on the average system (typical: 500)

Although you should be generous in your database sizing estimates, you must consider that size affects the time to conduct backups and adds load to other system resources. If the database is shared, its hardware and spacing are entirely dependent on what else is using it.