perfSONAR User Q&A and Other Discussion

[Shawn McKee <>]

Hi Andreas,

Thanks for the information.   It is useful feedback.

I would also point out a resource for OSG and WLCG perfSONAR toolkit users:  we have a perfSONAR support mailing list:      In addition we have a set of national/VO specific contacts listed at https://twiki.cern.ch/twiki/bin/view/LCG/NetworkTransferMetrics#Members   

If you have questions related to the use of the perfSONAR toolkit in WLCG (its configuration, monitoring or use) you can always email our support list.    Questions related to the operation of the toolkit and its services may be better directed to the perfsonar-user's list.   I know that for some issues it might be hard to decide who is the relevant contact.  If in doubt you can contact the wlcg-perfsonar-support list and we can help get the issue resolved.    

Thanks,

Shawn

On Tue, Mar 8, 2016 at 3:02 AM, Andreas Haupt <> wrote:

Hi Shawn,

On Mon, 2016-03-07 at 11:16 -0500, Shawn McKee wrote:
> Hi Andreas,
>
> Yes, it is a good suggestion to add some text to the deployment page about
> our current configuration.  I have updated the page at
> https://twiki.opensciencegrid.org/bin/view/Documentation/InstallUpdatePS#NoteOnBandwidthMesh

Thanks a lot!

> I would also note that this information is presented and discussed at our
> WLCG Network and Transfer Metrics WG meetings.    The change to the
> bandwidth meshes was discussed at couple different meetings and formally
> included in the Sep 30, 2015 meet ( see
> https://indico.cern.ch/event/400643/attachments/1162923/1675228/metrics_wg_30th_Sept.pdf
> )    You can see details on the group at
> https://twiki.cern.ch/twiki/bin/view/LCG/NetworkTransferMetrics     We
> discuss all the policy issues, plans and changes during those meetings and
> they are open to anyone who wants to attend. (I know attending yet another
> meeting is what everyone wants to do!)

Indeed. The list of products/services to be kept running by sites in
EGI/WLCG is rather (too?) long as of today. Fortunately, the development
speed decreased dramatically in that area during the last years. So
services set up once keep running rather stable. Nevertheless, as you
know, there is hardly time left to actively contribute to
developments. :-(

> I would like to get more details on your last paragraph:
>
> "Unfortunately the PerfSonar service became quite maintenance intensive
> over the last months. Additionally, it's not so easy to find the border
> between "vanilla PerfSonar product"-related problems and those that
> arise with the "WLCG configuration". "

Well, AFAIK PerfSonar is designed to run in an "appliance mode" - so
it's supposed to be run as "black box" that monitors your external
network connection. The PerfSonar documentation is really good but only
parts of it seems to be relevant for WLCG sites as most of the stuff is
configured automatically. Problems arise as soon as things are not
working as expected - then you have that rather large black box with
many different tools built in that need to be debugged ...

> One of our goals is to minimize the amount of maintenance the deployed
> WLCG/OSG toolkits require.   Can you let us know in what ways things have
> changed regarding maintenance at your site?   I would like to make sure we
> work on addressing problems so that other sites don't have to run into the
> same problems.

Disclaimer: I can just speak for our site here.

Only the rpm-based distribution is suitable for our environment.
Installation is straightforward, however, the automatic configuration is
full of assumptions that partly interfere with our local policies (ntp,
iptables, modified /root/.bashrc, ...).

These need to be adapted to the site's configuration system. However,
the PS installation is a "moving target" (its development speed is still
high): paths change, rpm names change, additional services are
introduced, configuration files need to get additional information, and
so on. All these (small) changes need a bit of adaptation work. But
summed up PerfSonar became a service that needs to be watched more or
less permanently in order to cope with the development process. So, the
paradigm "install it and forget about it" is just a wish as of today ...

One last point: the required long list of open ports in the firewall
(which results in many different exposed services) cause a latent "bad
feeling" about PS from the security point of view. Just wanted to
mention that ;-)

Cheers,
Andreas
--
| Andreas Haupt             | E-Mail:
|  DESY Zeuthen             | WWW:    http://www-zeuthen.desy.de/~ahaupt
|  Platanenallee 6          | Phone:  +49/33762/7-7359
|  D-15738 Zeuthen          | Fax:    +49/33762/7-7216