Worker Nodes on LHCOPN at WLCG Tier-1s
Survey on the status of deployment of Worker Nodes in the LHCOPN at WLCG Tier-1.
Site |
Current status |
Comments |
YES/NO |
CERN |
YES |
We verified that worker nodes both at CERN and at Wigner are all on the OPN. |
ASGC |
YES |
|
BNL |
No |
|
CNAF |
YES |
|
FNAL |
YES |
|
IN2P3 |
NO |
|
KISTI |
YES |
All cluster for ALICE T1 are to be in OPN (while joining OPN is in progress). |
KIT |
YES |
The WNs are behind a NAT, so access from the WNs to OPN-connected resources is possible, but all traffic goes through the NAT gateway. |
NDGF |
Only a split ALICE-T1/CMS-T2 cluster is on the OPN. |
Implementing local peering at all sites with the NDGF part of the OPN (not the entire LHCOPN), which means clusters can talk to the OPN via a local shortcut. After that, all clusters will be moved away from the OPN. |
NL-T1 |
No |
We don't mind if WNs of other sites approach our storage over the OPN but because of reasons related to firmware we are not able to put our WNs on the LHCOPN yet. |
PIC |
No |
No. WNs have private IPs (IPv4), then we cannot move then to OPN, the WN IP range is NAT'ed and enforced by the Internet access Firewall. Router connected to the LHCOPN does not have the NAT ability. Once we move to IPv6, the IPs could be public, and situation could be better for us. However, this would imply a re-definition of some of our internal VLANs and we are still investigating the impact. |
RAL |
No |
However we are in the process of reviewing this. Our concerns primarily relate to the loss of firewall/security monitoring and uncontrolled traffic flows when our SE is down |
TRIUMF |
YES |
The WNs are behind a NAT box which is on the LHCOPN. Note that our NAT traffic is limited to 1 Gbps by design and according to the current ATLAS use cases. |
--
JosepFlix - 23 Dec 2013