Content preview: We have a pool of 3 1U servers with 10GbE connectivity that
mount /ifs (and various subdirectories) over NFS. Each node has a set of
schedules that has a subset of the mount points added with -domain
statements.
If a node fails, we can move those schedules easily over to another node
while it's being repaired. We actually use this same technique for some
legacy
Hitachi/BlueARC storage, and it's worked well for that as well. [...]
Content analysis details: (0.6 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 IP_LINK_PLUS URI: Dotted-decimal IP address followed by CGI
0.0 NORMAL_HTTP_TO_IP URI: URI host has a public dotted-decimal IPv4
address
X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
X-Barracuda-Start-Time: 1518100638
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.28:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-Scan-Msg-Size: 6650
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.80
X-Barracuda-Spam-Status: No, SCORE=0.80 using global scores of TAG_LEVEL=3.5
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=BSF_SC7_SA015c, IP_LINK_PLUS,
NORMAL_HTTP_TO_IP
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.47712
Rule breakdown below
pts rule name description
---- ----------------------
--------------------------------------------------
0.00 NORMAL_HTTP_TO_IP Uses a dotted-decimal IP address in URL
0.00 IP_LINK_PLUS URI: Dotted-decimal IP address followed by
CGI
0.80 BSF_SC7_SA015c Custom Rule SA015c
We have a pool of 3 1U servers with 10GbE connectivity that mount /ifs (and
various subdirectories) over NFS. Each node has a set of schedules that
has a subset of the mount points added with -domain statements. If a node
fails, we can move those schedules easily over to another node while it's
being repaired. We actually use this same technique for some legacy
Hitachi/BlueARC storage, and it's worked well for that as well.
We don't use ACLs or anything beyond POSIX ownership and permissions, so
don't have to worry about that complexity. I think life would be much more
complicated if that were a requirement, though I would still try to find a
way to avoid NDMP.
On Wed, Feb 07, 2018 at 10:07:21PM -0500, Zoltan Forray wrote:
> Interesting. As I said, we have no NDMP experience and wasn't aware of the
> vendor specific process.
>
> As for your technique, can you elaborate some more? Where is the ISILON
> NFS mounted? To the TSM/ISP server? How do you preserve file rights?
> When our SAN guy pursued this (NFS) direction, an EMC forum discussion said
> it would not work since "NFS TSM backup would only backup the POSIX
> permissions and not the NTFS permissions" and since the ISILON is primarily
> accessed as DFS, the file attributes/rights is critical!
>
> On Wed, Feb 7, 2018 at 4:30 PM, Skylar Thompson <skylar2 AT u.washington DOT
> edu>
> wrote:
>
> > Content preview: I have stayed away from NDMP because it seems that it
> > locks
> > you into a particular vendor - if you use Isilon NDMP for backups,
> > then you
> > have to use Isilon NDMP for the restore. In a major disaster, I would
> > be
> > worried about the hassle of procuring compatible hardware/software to
> > do the
> > restore. We instead divide our Isilon storage up into separate NFS
> > mountpoints/TSM
> > filespaces and then point the client schedules at them with
> > "-domain='/ifs/dir1
> > /ifs/dir2'". We backup a 2PB OneFS filesystem in this manner, with
> > ~200 million
> > active files. [...]
> >
> > Content analysis details: (0.6 points, 5.0 required)
> >
> > pts rule name description
> > ---- ---------------------- ------------------------------
> > --------------------
> > 0.7 SPF_NEUTRAL SPF: sender does not match SPF record
> > (neutral)
> > -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
> > domain
> > X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
> > X-Barracuda-Start-Time: 1518039059
> > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
> > X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
> > X-Virus-Scanned: by bsmtpd at marist.edu
> > X-Barracuda-Scan-Msg-Size: 2463
> > X-Barracuda-BRTS-Status: 1
> > X-Barracuda-Spam-Score: 0.00
> > X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of
> > TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
> > X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.47680
> > Rule breakdown below
> > pts rule name description
> > ---- ---------------------- ------------------------------
> > --------------------
> >
> > I have stayed away from NDMP because it seems that it locks you into a
> > particular vendor - if you use Isilon NDMP for backups, then you have to
> > use Isilon NDMP for the restore. In a major disaster, I would be worried
> > about the hassle of procuring compatible hardware/software to do the
> > restore. We instead divide our Isilon storage up into separate NFS
> > mountpoints/TSM filespaces and then point the client schedules at them with
> > "-domain='/ifs/dir1 /ifs/dir2'". We backup a 2PB OneFS filesystem in this
> > manner, with ~200 million active files.
> >
> > We actually are moving away from Isilon for cost reasons though, and moving
> > towards GPFS. mmbackup removes a lot of the workload division complexity,
> > though adds other complexity at the same time. That said, it just invokes
> > dsmc behind the scenes, which means that we can restore our Isilon backups
> > to GPFS, and vice versa.
> >
> > On Wed, Feb 07, 2018 at 03:26:02PM -0500, Zoltan Forray wrote:
> > > As you recall, we have been trying to figure out an alternative method to
> > > backing up DFS mounted ISILON storage since the current method of 80+
> > > separate nodes accessed via the Web interface of the BA client is going
> > > away. Plus the backups are taking soooooo long, we have to determine a
> > > better way.
> > >
> > > So, doing some digging, one solution that seems to be touted is using
> > > NDMP.
> > >
> > > We have absolutely zero experience with NDMP and are looking for some
> > > guidance / cookbook / real-world experiences on how we would use NDMP to
> > > backup ISILON storage (>400TB and hundreds of millions of files) and make
> > > it accessible so someone from a help-desk like environment could handle
> > > file-level restores!
> > >
> > > Or if NDMP is the wrong direction, please tell us so.
> > > --
> > > *Zoltan Forray*
> > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > > Xymon Monitor Administrator
> > > VMware Administrator
> > > Virginia Commonwealth University
> > > UCC/Office of Technology Services
> > > www.ucc.vcu.edu
> > > zforray AT vcu DOT edu - 804-828-4807
> > > Don't be a phishing victim - VCU and other reputable organizations will
> > > never use email to request that you reply with your password, social
> > > security number or confidential personal information. For more details
> > > visit http://phishing.vcu.edu/
> >
> > --
> > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >
>
>
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://phishing.vcu.edu/
--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
|
