perfSONAR User Q&A and Other Discussion

[Hyojoon Kim <>]

Thank you for the answers! They really helped :-) 

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? 

Thanks,

Joon