|
I see. Nice!
Thanks for the detailed info about how mesh_config + cron actually works!
-Joon
On Jun 22, 2015, at 10:51 AM, Daniel Doyle <> wrote:
On Jun 19, 2015, at 5:43 PM, Hyojoon Kim <> wrote:
Thank you for the answers! They really helped :-)
Happy to help out. :)
On Jun 19, 2015, at 5:21 PM, Daniel Doyle <> wrote:
On Jun 19, 2015, at 5:02 PM, Hyojoon Kim <> wrote:
1. Can an MA host server be a MaDDash server and a central mesh configuration server, altogether at the same time? Maybe also a host with perfSONAR Toolkit installed? If possible, is this a good choice of design? I am asking because we have one
host that we want to use as a measurement point, configuration server, visualization server, and as a place to store measurement data because it has lots of storage space.
Yes, you can do this. In terms of whether it's a good choice of design, I expect you will get different answers from different people for different reasons. :)
As long as the host is suitably provisioned such that it's not maxed out on CPU or swapping on memory or anything like that, you should be fine. The answer to "suitably provisioned" depends on how busy it's going to be - how many regular tests
are running, how many users are pulling data from the MA, etc.
I see. I guess we should make your our central server does not have too much working going on.
2. Does MaDDash make sense even if all the data are stored in your central server?
Yes. Storing data in a central server only means that the result data is centralized. The results store what the src/dst were, not where they were stored. The tests still happen on their respective endpoints and are documented as such, they just
reported the results back to the central server. MaDDash reports on the results of these tests, so whether it's pulling in data from a hundred different MAs or just a single one the end result to the user is the same. It will show the correct src/dst information
even if stored in a central MA.
Nice!
The regular_testing.conf file is derived from the mesh config when used in a mesh configuration. Basically you set up the mesh config and put it into a web accessible place. Various clients download it and convert that into a regular_testing.conf
file for all the bits that are important to that host. The regular testing process then reads that and performs the test as if you had configured it from the UI. Since all the clients are doing this, they all wind up testing to eachother and end up making
a mesh.
I see. So the individual regular_testing.confs are automatically derived from the mesh config, and we can probably manual revise or fix that regular_testing.con too?
Partially, yes. The tests themselves get filled out by the mesh configuration agent. The regular_testing.conf file needs to be filled out a little by hand so that your MA API key is there to authorize test submissions for example.
The mesh configuration on the test hosts can be run via cron so that updates to the central config are automatically pulled in. The file gets installed to `/etc/cron.d/cron-mesh_config_agent`, and you can take a look at what it's doing. If this
cron file is there and your mesh config agent is set up correctly, then it will redownload the central mesh config periodically and restart regular testing so that the new tests start.
Dan Doyle
GlobalNOC Software Developer
1-812-856-3892
|
