Hello,
So I have 5 separate VM's running now. One dedicated to NAV and PostgreSQL, with ipdevpoll running in multiprocessor mode.
Another is dedicated to carbon-relay and the main graphite webapp. This small VM sends the metrics to three other servers running carbon-caches (also fronted by carbon-relay). The three dedicated servers are older (one quad-core cpu), although I added SSD's to them. This is why my installation is scaled in a more complicated manner. I do hope this all makes sense.
Everything is now running great, however there is one issue: When viewing the netmap, the bandwidth usage does not update across all links. Some links show a color for the corresponding load, but some show as grey and never update.
Of course this issue arose after I moved Graphite/Carbon into four separate servers.
I hope this makes sense. Thank you for your guys' time.
-----Original Message----- From: nav-users-request@uninett.no [mailto:nav-users-request@uninett.no] On Behalf Of Morten Brekkevold Sent: Friday, August 31, 2018 4:25 AM To: William Daly - Network Specialist, VUSD Technology WilliamD@VUSD.SolanoCOE.K12.CA.US Cc: nav-users@uninett.no Subject: Re: Separating back-end processes
On Thu, 16 Aug 2018 21:23:13 +0000 "William Daly - Network Specialist, VUSD Technology" WilliamD@VUSD.SolanoCOE.K12.CA.US wrote:
The metrics that were currently collect only keep increasing overtime. We would like to separate the various parts of NAV on to different servers to spread the resource burden.
I assume you've already gone down the path of multiprocess ipdevpoll?
I have explored the idea of moving postgres and carbon to a different server. What would you recommend? Can I get away with just clustering Carbon?
The largest installation under our control consists of three separate hardware servers: One for NAV, one for PostgreSQL, and one for Graphite/Carbon.
This split is simple to execute, and quickly improves the performance of large installations. We always recommend storing Graphite data on SSDs, and we never run less than 2 carbon-cache processes (fronted by carbon-relay) on a server. On a dedicated server, one carbon-cache process per core is probably a good goal.
We do have some future plans for extending the ipdevpoll multiprocess mode to include remote processes for either distributed collection or proxying, but I at the moment I cannot say when we will have time to look at it.
-- mvh Morten Brekkevold Uninett