<div dir="ltr"><div><br>I would be very weary about stretching a cluster between DMZ's. IMHO the nodes are too tighly connected for that. <br><br>I just saw the Desy/GPFS talk at IBM technical university in Cannes, and it was mentioned that you had moved from 60 MB/s to 600 MB/s from un-tuned to tuned NFS over 10GbE. Sounded quite impressive. Are you saying putting FTP on top of those 600 MB/s kills the performance / download rate? <br><br>Maybe AFM, with readonly Cache, would allow you to get better performance by caching the content on the FTP-servers ? Then all you should need of openings between the DMZ's would be the NFS-port for a readonly export..<br><br><br><br></div><div>  -jf<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 9:49 PM, Martin Gasthuber <span dir="ltr"><<a href="mailto:martin.gasthuber@desy.de" target="_blank">martin.gasthuber@desy.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the path via NFS is already checked - problem here is not the bandwidth, although the WAN ports allows for 2 x 10GE, its the file rate we need to optimize. With NFS, in between GPFS and FTP, we saw ~2 times less file download rate. My concern are also not really about raw IB access and misuse - its because IPoIB, in order to minimize the risk, we had to reconfigure all other cluster nodes to refuse IP connects through the IB ports from that node - more work, less fun ! Probably we had to go the slower NFS way ;-)<br>
<br>
best regards,<br>
  Martin<br>
<div class="HOEnZb"><div class="h5">> On 2 Nov, 2015, at 16:22, Wahl, Edward <<a href="mailto:ewahl@osc.edu">ewahl@osc.edu</a>> wrote:<br>
><br>
> First off let me recommend vsftpd.   We've used that in a few single point to point cases to excellent results.<br>
><br>
> Next, I'm going to agree with Johnathan here, any hacker that someone gains advantage on an FTP server will probably not have the knowledge to take advantage of the IB, however there are some steps you could take to mitigate this on a node such as you are thinking of:<br>
><br>
> -Perhaps an NFS share from an NSD across IB instead of being a native GPFS client?  This would remove any possibility of escalation exploits gaining access to other servers via SSH keys on the IB fabric but will reduce this nodes speed of access.  On the other hand almost any  IB faster than SDR probably is going to wait on the external network unless it's 40Gb or 100Gb attached.<br>
><br>
> -firewalled access and/or narrow corridor for ftp access. This is pretty much a must.<br>
><br>
> -fail2ban like product checking the ftp logs. Takes some work, but if the firewall isn't narrow enough this is worth it.<br>
><br>
> Ed Wahl<br>
> OSC<br>
><br>
><br>
> ________________________________________<br>
> From: <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a> [<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a>] on behalf of Martin Gasthuber [<a href="mailto:martin.gasthuber@desy.de">martin.gasthuber@desy.de</a>]<br>
> Sent: Monday, November 02, 2015 8:53 AM<br>
> To: gpfsug main discussion list<br>
> Subject: [gpfsug-discuss] GPFS (partly) inside dmz<br>
><br>
> Hi,<br>
><br>
>  we are currently in discussion with our local network security people about the plan to make certain data accessible to outside scientists via ftp - this implies that the host running the ftp daemon runs with their ethernet ports inside a dmz. On the other hand, all NSD access is through IB (and should stay that way). The biggest concerns are around the possible intrude from that ftp host (running as GPFS client) through the IB infrastructure to other cluster nodes and possible causing big troubles on the scientific data. Did anybody here has similar constrains and possible solutions to mitigate that risk ?<br>
><br>
> best regards,<br>
>  Martin<br>
><br>
> _______________________________________________<br>
> gpfsug-discuss mailing list<br>
> gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
> _______________________________________________<br>
> gpfsug-discuss mailing list<br>
> gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</div></div></blockquote></div><br></div>