perfsonar development work

["Jeff W. Boote" <>]

Nicolas Simar wrote:
> Well, I suggested each NREN/domain to have its own LS because our 
> experience
> here at ISTF shows that having more than ~100 interfaces registered by RRD
> MA(s) in LS every 30 seconds puts too much stress on our server (shared
> between RRD MA-J, RRD MA-P and LS, 768 MB RAM, 1 GHz CPU). In fact we were
> forced to reduce the number of published interfaces to 80 and the 
> registration
> frequency to once every 120 seconds. A more powerful server (or a 
> dedicated LS
> server) might be able to handle a bigger load. However, I doubt whether a
> single LS would be able to handle several thousands of items efficiently 
> right
> now. That's why a more scalable approach (at least for the time being) 
> would
> be to spread the load between a higher number of LS (ideally, hosted by 
> every
> NREN/domain). Of course, some NRENs/domains might prefer to register a 
> small
> number of items in the LS of another NREN/domain, willing/able to host this
> info without any impact on performance.
>
> I'm also wondering if it would be a good idea to configure all these 
> NREN LSs
> to register in some "top level" LS, whose sole purpose would be to
> host/provide information for the location of other LSs (without details for
> interfaces or other data items). This might be an efficient and scalable 
> setup
> for the time being, while the work on Multi-LS goes forward. It would 
> provide
> a single point of entry for visualization clients, instead of the otherwise
> unavoidable full list of the addresses of all available LSs, which has 
> to be
> updated manually quite frequently. If we decide to deploy such "top 
> level" LS,
> the best place for it would be in a location with highly redundant network
> connections and power supplies, as well as responsive operational support.
> Some hints could be provided by our SmokePing statistics of RRD MA services
> availability:

I agree with this 'goal'. But, I would worry about adding this logic directly in 
the client. The hierarchical reference here should be part of the discovery 
protocol, and should specifically be developed as part of the multi-ls design 
and development work...


> NREN                 RRD MA AVAILABILITY (last 90 days)
>
> Abilene              88.21%
> ISTF/ACAD (Java)     99.19%
> CARNet               93.54%
> Cesnet               65.54%
> ESnet                98.59%
> GEANT                99.93%
> GRNET                83.84%
> MREN                 60.81%
> PIONIER (RRD)        69.98%
> RNP                  99.60%
> SEEREN               99.96%
> SWITCH               90.26%
> Uninett              99.53%
>
> SEEREN has the highest availability, closely followed by GEANT, RNP, 
> Uninett
> and ISTF in decreasing order of preference. When taking into account 
> network
> latency from different points in the world, as well as "politics", I would
> certainly vote for GEANT to host the "top level" LS in which all other LS
> would have to register.
>
> The American guys are below the 99% threshold and this cannot be 
> justified by
> failing intercontinental network connections, as demonstrated by:

Our RRD has not been supported in a production environment in any way. It is on 
a development server. The same one running bugzilla and doing half-a-dozen other 
things. If we ran a production service, it would NOT be on one of our 
development systems. It would be in our NOC and would be a supported service.

jeff