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 <[email protected]> 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 <[email protected]> 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: [email protected] [ > [email protected]] on behalf of Martin Gasthuber [ > [email protected]] > > 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 >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
