toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

Backup failures
by Bhavnesh Makin 07 Dec '99

07 Dec '99

We are using budtool 4.6.1 to backup our filers over the network. Recently we have noticed a problem where backups have failed with following error: Ldi (:budgo.c:4130) 11/23/99 22:06:23> Waiting for the ndmp2fh process to finish ... Ldi (:budgo.c:4131) 11/23/99 22:06:23> More backup data is coming from the socket ... Ldi (:budgo.c:4130) 11/23/99 22:06:25> Waiting for the ndmp2fh process to finish ... Ldi (:budgo.c:4131) 11/23/99 22:06:25> More backup data is coming from the socket ... L00 (:debug.c:1325) 11/23/99 22:06:26> ****************************************************************** L00 (:debug.c:1327) 11/23/99 22:06:26> ------ E R R O R ------- E00 (:debug.c:1327) 11/23/99 22:06:26> Command exceeded maximum allowable run time 78800. L00 (:debug.c:1341) 11/23/99 22:06:26> ****************************************************************** Parsing through the log file everything looks fine i.e. snapshots get created for backups, data gets dumped and snapshots get deleted. I opened up ticket with netapp folks but of no help yet. I went ahead and upgraded the ontap version on one of my F740 filers to 5.2.3 from 5.2.2P1D2 and problem went away for little while, but it has reappeared again. Any thoughts, Bhavnesh Makin

3 2

RE: experiences with clustering and snapmirror
by Anders Ljungberg S (QDT) 07 Dec '99

07 Dec '99

Joe. I'll give you a simple picture of the setup we're having at Ericsson In Stockholm serving 8000 users today. 6 F760 in cluster pairs all them primary owner of 750GB Disk 3 F760 Standalone Snapmirror replicas In total ~9TB of disk The're running in a mixed CIFS & UNIX Enviroment. We installed this setup in the begining ot the year and runned across a couple of bugs in the cifs implementation. But overall we're realy happy with what we're having and most important it's doing lots of good for the organisation using it. This is a few hints. - Clustering works great! Booth manual and automatic. - Snapmirror , i would not put my mirrors on the same heads. Fist of all i like to move the data to a different location. Putting the mirrors on the cluster heads make's the supported amount of data stored on each head go down ( Today thers is a 750 GB limit in cluster configs due to sharing NVRAM etc. ) It's realy fast to make a snapmirror head take the place of a destroyed cluster. With the standard trottle it's not taking to much power out of the heads. We are pointing the snapmirror traffic to "dedicated" NIC's on the heads so it does'nt interfear with client traffic. We take our backups from the snapmirror heads on a separat "Storage SAN" which gives us a larger backup window and does'nt effect the clients in any way. No snapshots, the mirrored volumes are read only. - Network balancing , today there is no failover/balancing support in my GB NIC's i keep 3 in every head. One for client access, one for fail over and one for snapmirroring. I heard there is going to be GB Ether Channel support, which would give failover/loadbalancing try to get an update from your sales rep. - WAFL , no problems snapshots makes it easy for the users to recover files them self. The raid is working good. snapshots saved us a coupple of times. - NFS I havent been across any problems with any NFS platform ( SUN, HP , IBM etc ) Just realy good NFS performance. Let me know it there is any thing a can answer for you. Good Luck Anders Ljungberg -----Original Message----- From: Joe Gross [mailto:jgross@stimpy.net] Sent: Tuesday, December 07, 1999 7:47 AM To: toasters(a)mathworks.com Subject: experiences with clustering and snapmirror We're currently evaluating several solutions for hosting initially about 1TB but will probably grow to several times that over the next 18 months. We already have a small 740 happily chugging away for the past 4 months and have been extremely happy with it. The configuration we're considering is clustering two F760s. Each filer will serve its own data and also be physically connected to the disks that the other filer serves. From what I understand this is the standard clustering configuration. We would plan to add more filers in pairs as we outgrow the initial pair. The main NFS clients would be bunch of suns that run as application servers. They'll take requests, munge data and return results back to other parts of the site. All the application servers would be able to see all the data. Since the application servers don't hold any data they would all be identical (and expendable.) In addition, we're considering adding a second raid volume to each filer and using snapmirror against the other filer's primary volume. This would protect us against the possibility of one of the primary raid devices having a catastrophic failure. We'd run snapmirror every five minutes or so to keep the secondary updated. Each filer would have a primary and secondary ethernet interface connected to different edge devices on a switched GB network. This would assure that if a network edge device went down the filer would still be able to reach the backbone. Backups would happen with traditional methods using a snapshot of the mirror copy. Here's a cheap ascii picture of what I poorly described above: +---------------+ +---------------+ |snapmirror of | |snapmirror of | |filer 2 primary| |filer 1 primary| +---------------+ +---------------+ | | | +-------+ | | +-------|filer 1|-------+ | | | |primary| | | +-------+ | disks | +-------+ gb ether---| | +-------+ | |---gb ether |filer 1| |filer 2| gb ether---| | | |---gb ether +-------+ +-------+ +-------+ | |filer 2| | +--------|primary|--------+ | disks | +-------+ gb ether gb ether gb ether gb ether gb ether gb ether | | | | | | +------+ +------+ +------+ +------+ +------+ +------+ | app | | app | | app | | app | | app | | app | |server| |server| |server| |server| |server| |server| +------+ +------+ +------+ +------+ +------+ +------+ I'm looking for any experiences you have had with this or any subset of the picture. Specifically, I'd like to hear experiences about - Clustering: Does it work for you? Have you had a filer die and had the secondary take over? Have you had a filer die and the secondary NOT take over? - Snapmirror: Do you use it? How does frequent mirroring affect performance of both the sending and receiving systems? Have you had any consistency or other problems with it? Can you take snapshots of the receiving disk? - Multiple paths to the network. Can you aggregate bandwidth through multiple gigabit connections to the same network? What about setting one interface as the primary and the other as a secondary? - WAFL: Good or bad things to say about the filesystem. - NFS issues. NFS is famous for problems with lockups, locking problems, stuck mounts, etc. We won't be doing any locking over NFS mounts and will be using whatever version of solaris is recommended at the time. Anything good or bad that can be said about the combination of a netapp and sun. Any other information or advice regarding this arrangement would, of course, be welcome. This is being considered as an alternative to the traditional method of hanging a RAID off each server but there are still some big hangups about NFS in general. Good (or bad) experiences regarding this would be appreciated. Thanks for reading this far and thanks in advance for any knowledge you can pass on. Joe Gross

1 0

experiences with clustering and snapmirror
by Joe Gross 07 Dec '99

07 Dec '99

We're currently evaluating several solutions for hosting initially about 1TB but will probably grow to several times that over the next 18 months. We already have a small 740 happily chugging away for the past 4 months and have been extremely happy with it. The configuration we're considering is clustering two F760s. Each filer will serve its own data and also be physically connected to the disks that the other filer serves. From what I understand this is the standard clustering configuration. We would plan to add more filers in pairs as we outgrow the initial pair. The main NFS clients would be bunch of suns that run as application servers. They'll take requests, munge data and return results back to other parts of the site. All the application servers would be able to see all the data. Since the application servers don't hold any data they would all be identical (and expendable.) In addition, we're considering adding a second raid volume to each filer and using snapmirror against the other filer's primary volume. This would protect us against the possibility of one of the primary raid devices having a catastrophic failure. We'd run snapmirror every five minutes or so to keep the secondary updated. Each filer would have a primary and secondary ethernet interface connected to different edge devices on a switched GB network. This would assure that if a network edge device went down the filer would still be able to reach the backbone. Backups would happen with traditional methods using a snapshot of the mirror copy. Here's a cheap ascii picture of what I poorly described above: +---------------+ +---------------+ |snapmirror of | |snapmirror of | |filer 2 primary| |filer 1 primary| +---------------+ +---------------+ | | | +-------+ | | +-------|filer 1|-------+ | | | |primary| | | +-------+ | disks | +-------+ gb ether---| | +-------+ | |---gb ether |filer 1| |filer 2| gb ether---| | | |---gb ether +-------+ +-------+ +-------+ | |filer 2| | +--------|primary|--------+ | disks | +-------+ gb ether gb ether gb ether gb ether gb ether gb ether | | | | | | +------+ +------+ +------+ +------+ +------+ +------+ | app | | app | | app | | app | | app | | app | |server| |server| |server| |server| |server| |server| +------+ +------+ +------+ +------+ +------+ +------+ I'm looking for any experiences you have had with this or any subset of the picture. Specifically, I'd like to hear experiences about - Clustering: Does it work for you? Have you had a filer die and had the secondary take over? Have you had a filer die and the secondary NOT take over? - Snapmirror: Do you use it? How does frequent mirroring affect performance of both the sending and receiving systems? Have you had any consistency or other problems with it? Can you take snapshots of the receiving disk? - Multiple paths to the network. Can you aggregate bandwidth through multiple gigabit connections to the same network? What about setting one interface as the primary and the other as a secondary? - WAFL: Good or bad things to say about the filesystem. - NFS issues. NFS is famous for problems with lockups, locking problems, stuck mounts, etc. We won't be doing any locking over NFS mounts and will be using whatever version of solaris is recommended at the time. Anything good or bad that can be said about the combination of a netapp and sun. Any other information or advice regarding this arrangement would, of course, be welcome. This is being considered as an alternative to the traditional method of hanging a RAID off each server but there are still some big hangups about NFS in general. Good (or bad) experiences regarding this would be appreciated. Thanks for reading this far and thanks in advance for any knowledge you can pass on. Joe Gross

1 0

test
by Michael Linett 06 Dec '99

06 Dec '99

-- Michael Linett - President Mike(a)zerowait.com * http://www.zerowait.com PH 302.266.9408 FX 302.738.4302 http://www.loadbalancing.net - The Source for information on Load Balancing Technology http://www.nas-san.com - Information on Network Attached Storage and Storage Area Networks

1 0

RE: RE: HP OmniBack Backup Filer on NT DLT
by Benn, Paul 03 Dec '99

03 Dec '99

I personally have not used OmniBack but I did publish a white paper on the subject of NT based backup of filers. At the very least, it may give you some ideas. http://www.netapp.com/tech_library/3052.html Regards, Paul Benn Network Appliance -----Original Message----- From: Dave Mills [mailto:davem@cypress-systems.com] Sent: Friday, December 03, 1999 10:11 AM To: toasters(a)mathworks.com Subject: RE:RE: HP OmniBack Backup Filer on NT DLT We are new to filers. We currently have several DLT drives on NT servers which are OmniBack tape agents. We are currently getting ready to install a F720. Has anyone used OnmiBack on NT to backup via the CIFS on a filer? I know we would have to snapshot manually. Any other drawbacks or problems? Dave Mills Cypress Systems

1 0

RE:RE: HP OmniBack Backup Filer on NT DLT
by Dave Mills 03 Dec '99

03 Dec '99

We are new to filers. We currently have several DLT drives on NT servers which are OmniBack tape agents. We are currently getting ready to install a F720. Has anyone used OnmiBack on NT to backup via the CIFS on a filer? I know we would have to snapshot manually. Any other drawbacks or problems? Dave Mills Cypress Systems

1 0

OOps
by Jay Orr 02 Dec '99

02 Dec '99

Ignore last post -- our mail queue is slow and I just got the messages previously posted. Thanks for addressing the concern, Netapps! ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

1 0

Netapp Web Page
by Jay Orr 02 Dec '99

02 Dec '99

Had anyone heard if Netapp is planning to make their support page LYNX / text browser compliant?? I see they revamped their page, and I remember the thread about how netapps support page requires javascript, so no text-based browsers work (so if you working off of a VT term, your SOL). Has this question been resolved at Netapps? Is the revamp still using javascript a way of saying they could care less about this issue? ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

1 0

FW: FTP uploads from the UK (fwd)
by Nguyen, Alan 02 Dec '99

02 Dec '99

To All, First, I must apologize for NetApp's poor FTP site performance. The responsibility for this in my group. The situation is our internet connection is highly-utilized and thus your access to our FTP site is affected by this. Actions have been taken to increase internet bandwidth in the next few weeks. However, despite this, it will be superseded by our new FTP implementation. We have designed a new FTP site to improve security, system management, increase internet bandwidth/presence (i.e. ISP hosted site), and system redundancy. Because our current infrastructure is very out-dated, we have taken the "big-bang" approach rather than making incremental improvements. In a little more detail, our new FTP site is at a web-hosted site with 100MB bandwidth capacity vs current T1, and is configured with two fail-over dual-processor Unix systems with cluster fail-over (F760) Filer pair for storage. In short, the new site is very robust and will scale to meet to our customers' needs. What has been done thus far? Contract has been signed with new web-hosting site. Networking infrastructure is in place. Programming is complete for account and directory management. The new systems are racked at the new web-hosted site. As I type this, we are plugging in the cables for the new systems. What's the schedule? In the next two days, we will perform internal/external FTP tests. On Monday (Dec 6th), we will start live tests with customers assuming everything goes well this week. After which, the new site will go live. I will announce to this list when we are live. If you have any questions, please direct them to me anguyen(a)netapp.com <mailto:anguyen@netapp.com> or reply to this list as I will be joining this list soon. Again, thank you for your patience. Alan Nguyen Network Appliance Mgr., IT Server Operations

1 0

RE: User Quotas in CIFS Environment
by Plawner, Marom 02 Dec '99

02 Dec '99

I realize that the responses I received on this thread weren't posted to the group, so I'll give a quick overview of the e-mail's I received: Problem that users from the NT domain must be migrated into the /etc/passwd file (using the dos based on beta GUI based tool) to be able to give a users@tree quota. Responses: This is not unique to my system. It is in fact built this way. I've been told that this should be changed in an upcoming release (less than 12 months, hopefully). Quote, "The quota system within WAFL needs to be wired to the NTFS metadata that is maintained in the NTFS and MIXED file system styles. Currently it is only wired to the UNIX notion of ownership, which is why the UNIX<->NT user mappings are currently necessary to make user and group quotas work for Windows users." My Reaction: 12 months!!!! Problem: An NT based NIS server and make the NetApp a client. Anyone know of one? Responses: Good idea, nope, we don't. Problem: The DOS based migration tool crashes, can someone at NetApp fix it? Response: Nope. We don't even have the source, and we don't support it. My Reaction: This is a BAD answer. The NetApp filer provides a broken functionality (see first problem above), and the only interim solution isn't supported. Problem: Maybe the GUI version of the migration tool has hidden command line switches which can make it scriptable? Response: Nope. Why don't you just write your own script automatically update your /etc/passwd file? My Reaction: I bought the NetApp Filer since it's supposed to be a "black box" (ok, blue). The concept of the filer is that it is a simple, closed system that you just plug in a go with. If I wanted a system which I have to start building tools for, I'd download Linux for free and do it myself. (Or run Novell, or suffer with speed of NT.) Speed wasn't the issue, NetApp people... simplicity was. I don't need "just go and program it yourself" answers. I bought this for a CIFS environment, not NFS. I don't come from the "just build it in Perl" side of the tracks. Since you offer more functionality, you just understand your customer based and how the NT System Admins are different than the Unix System Admins. Problem: Maybe the wafl.nt_user.default option is connected? Response: No, read the man page. My Reaction: Right, good idea. Thanks to all of your responses. For those of you wanting to go into CIFS or using CIFS and wanting to go into quotas, I was given a suggestion to just limit the size of the /users folder. In theory it isn't a bad idea, but I'll tell you from the point of view of a company with about 4,000 people using the filer as a home directory, people will use it all up and fast! Not putting a quota won't work. - Marom

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters