[gpfsug-discuss] GPFS (partly) inside dmz

Jan-Frode Myklebust janfrode at tanso.net
Tue Nov 3 09:16:09 GMT 2015


I would be very weary about stretching a cluster between DMZ's. IMHO the
nodes are too tighly connected for that.

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?

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..



  -jf


On Mon, Nov 2, 2015 at 9:49 PM, Martin Gasthuber <martin.gasthuber at desy.de>
wrote:

> 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 ;-)
>
> best regards,
>   Martin
> > On 2 Nov, 2015, at 16:22, Wahl, Edward <ewahl at osc.edu> wrote:
> >
> > First off let me recommend vsftpd.   We've used that in a few single
> point to point cases to excellent results.
> >
> > 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:
> >
> > -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.
> >
> > -firewalled access and/or narrow corridor for ftp access. This is pretty
> much a must.
> >
> > -fail2ban like product checking the ftp logs. Takes some work, but if
> the firewall isn't narrow enough this is worth it.
> >
> > Ed Wahl
> > OSC
> >
> >
> > ________________________________________
> > From: gpfsug-discuss-bounces at spectrumscale.org [
> gpfsug-discuss-bounces at spectrumscale.org] on behalf of Martin Gasthuber [
> martin.gasthuber at desy.de]
> > Sent: Monday, November 02, 2015 8:53 AM
> > To: gpfsug main discussion list
> > Subject: [gpfsug-discuss] GPFS (partly) inside dmz
> >
> > Hi,
> >
> >  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 ?
> >
> > best regards,
> >  Martin
> >
> > _______________________________________________
> > gpfsug-discuss mailing list
> > gpfsug-discuss at spectrumscale.org
> > http://gpfsug.org/mailman/listinfo/gpfsug-discuss
> > _______________________________________________
> > gpfsug-discuss mailing list
> > gpfsug-discuss at spectrumscale.org
> > http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20151103/04647b0b/attachment-0002.htm>


More information about the gpfsug-discuss mailing list